Route Base VPN problem

[Jirka1]

Hello, I'm trying to set site 2 site IPsec VPN site between 60E and 100D to route all traffic from a specific 60E port to IPsec tunnel (remote browsing). I used a route-based VPN. The minor problem was with the default router, but it was possible to resolve it by setting priorities. The central unit is 100D in the A/P cluster. Behind it is Win2008 (AD, DNS, DHCP) and using DHCP relay at 60E

allocates addresses to clients via IPsec tunnel. It all works. However, the customer's requirement is also the use of two additional ports on the 60E which must go through the WAN interface directly (with NAT) to the Internet (outside the IPsec tunnel). I set the interface, IP ranges, DHCP, DNS, Policy ... Unfortunately, the internet from these networks was inaccessible. I was looking for why and the problem is lower priority (2) default routing for IPsec tunnel - 0.0.0.0/0->TUNNEL  than default route 0.0.0.0/0->DEFAULT GW (4). So I tried to use Policy Routing to define that these two networks should route traffic directly to WAN. Unfortunately, this is not the case. Unfortunately, it does not work So I set up a Policy Base VPN between 60E and 100D. Now all networks are working, but traffic generated at 60E (ping, connect to FAZ, etc.) all goes through this IPsec tunnel, which is undesirable.

How to best solve this scenario? Ideally using a route-based VPN?

Thank you.

[Allan_Lago]

Hi,

You could do the opposite. Create a route 0.0.0.0/0->DEFAULT GW (4) and then create a policy route to match only the traffic you want to go trought the VPN, e.g.

172.16.0.0/24 -> TUNNEL

172.160.1.0/24 -> TUNNEL

You shouldnt have any problems with route based vpn, in fact they usually have better usage then policy based vpns.

Hope it helps.

[Jirka1]

Hi, problem is, that I need all traffic through the tunnel from specific subnet/interfaces. Not only some subnet. And if I create two default routes 0.0.0.0/0 (one with priority 2 to the tunnel and one with priority 4 to the wan gw), traffic from interface, which I won't routed to tunnel is routed to tunnel :\

[oheigl]

Yeah but that's exactly what he meant, configure the WAN gateway route with lower priority than the one into the VPN tunnel (lower priority means actually that it's preferred to the higher priority value). After that, create a policy route with source and destination 0.0.0.0 pointing to the VPN tunnel, and set the source interface to the specific interface which should go through the VPN. This should work just fine :)

[Jirka1]

Oheigl thanks,  I set it according to your instructions. Everything works, but I can´t go anywhere to the internet from 60E. Only to default gateway. Ping does not work anywhere to the internet, I will not be able to join FAZ or FMG. If I set static routes to individual destinations (FAZ, FMG), everything works. Is it feature or wrong setting? Thanks Jirka  

config system interface
    edit "wan1"
        set vdom "root"
        set ip 62.xxx.xxx.xxx 255.255.255.192
        set allowaccess ping https ssh snmp
        set type physical
        set alias "WAN"
        set role wan
        set snmp-index 1 
next 
edit "internal2"
        set vdom "root"
        set dhcp-relay-service enable
        set ip 172.17.14.1 255.255.255.0
        set allowaccess ping https ssh http
        set type physical
        set alias "CUST LAN"
        set device-identification enable
        set role lan
        set snmp-index 9
        set dhcp-relay-ip "172.16.10.2" 
 next
 edit "XDC"
        set vdom "root"
        set ip 10.10.20.1 255.255.255.0
        set allowaccess ping
        set role lan
        set snmp-index 5
        set interface "internal2"
        set vlanid 1000
 next
 edit "UniFi"
        set vdom "root"
        set ip 10.33.1.1 255.255.255.0
        set allowaccess ping
        set role lan
        set snmp-index 15
        set interface "internal2"
        set vlanid 1001 
next
config router static
    edit 3
        set gateway 62.xxx.xxx.xxx
        set priority 2
        set device "wan1"
    next
    edit 2
        set priority 1
        set device "IPsec->HQ"
    next
end
config router policy
    edit 1
        set input-device "internal2"
        set srcaddr "all"
        set dstaddr "all"
        set output-device "IPsec->HQ"
    next
    edit 2
        set input-device "XDC"
        set srcaddr "XDC"
        set dstaddr "all"
        set gateway 62.xxx.xxx.xxx
        set output-device "wan1"
    next
    edit 3
        set input-device "UniFi"
        set srcaddr "UniFiGuest"
        set dstaddr "all"
        set gateway 62.xxx.xxx.xxx
        set output-device "wan1"
    next
end 
config firewall policy
    edit 4
        set uuid 16b6d6f2-90a9-51e7-50d6-28c75b7038db
        set srcintf "UniFi"
        set dstintf "wan1"
        set srcaddr "UniFiGuest"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
    edit 5
        set uuid 328c1e1e-90a9-51e7-a976-255cf2cc7aae
        set srcintf "XDC"
        set dstintf "wan1"
        set srcaddr "XDC"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
    edit 3
        set uuid 4bf13740-9144-51e7-86ff-1d4e03ca6ca3
        set srcintf "internal2"
        set dstintf "IPsec->HQ"
        set srcaddr "CUST LAN"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
    edit 6
        set uuid 56347e10-9144-51e7-ffac-a6f54c96de19
        set srcintf "IPsec->HQ"
        set dstintf "internal2"
        set srcaddr "all"
        set dstaddr "CUST LAN"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next 

[oheigl]

Well your priority in the second route is still lower than the one via WAN1 (or did you change it back because it didn't work?)

What you mean by can't go anywhere to the internet - Do you mean traffic that originates from the FortiGate or isn't it working for the XDC clients neither?

In my point of view if you change the priority on the wan1 interface to 0 it should work!

[Jirka1]

Yes, if I set default WAN route to a lower priority (1) than the default tunnel route (2), it does not work. The other two networks (UniFi and XDC) are working and as well as the traffic coming from FortiGate, but the IPsec tunnel is not...the client does not obtainan IP address from DHCP, and if I set static, it does not work.

[oheigl]

Wait you are receiving the DHCP via the VPN tunnel for the internal2 clients? Can you start a sniffer for this kind of traffic in the situation where it is not working?

diag sniffer packet any 'net 172' 4 0 a

If you want to debug only DHCP you can filter it further:

diag sniffer packet any 'net 172 and (port 67 or port 68)' 4 0 a

I'm not sure how much and what type of traffic is going through your device.

[Jirka1]

Ok,

I made test with priority of route. The first sniff is the lower priority (1) WAN route. No response from DHCP server behind of tunnel. 

FGT60-IGY # diag sniffer packet any 'net 172 and (port 67 or port 68)' 4 0 a

interfaces=[any]
filters=[net 172 and (port 67 or port 68)]
2017-09-04 09:05:44.702483 wan1 out 172.17.14.1.67 -> 172.16.10.2.67: udp 301
2017-09-04 09:05:48.949704 wan1 out 172.17.14.1.67 -> 172.16.10.2.67: udp 301
2017-09-04 09:05:56.833940 wan1 out 172.17.14.1.67 -> 172.16.10.2.67: udp 301
^C
4 packets received by filter
0 packets dropped by kernel

The second snif is the higher (2) priority WAN route. This is correct behavior and client got an IP address. 

FGT60-IGY # diag sniffer packet any 'net 172 and (port 67 or port 68)' 4 0 a

interfaces=[any]
filters=[net 172 and (port 67 or port 68)]
2017-09-04 09:07:41.726772 IPsec-HQ out 172.17.14.1.67 -> 172.16.10.2.67: udp 335
2017-09-04 09:07:41.736961 IPsec-HQ in 172.16.10.2.67 -> 172.17.14.1.67: udp 309
2017-09-04 09:07:41.737180 internal2 out 172.17.14.1.67 -> 172.17.14.22.68: udp 309

[oheigl]

Hm okay, that's annoying - it's not working because the relay is like self originating traffic from the FGT, so the policy route is not checked. Just for testing, can you add a route for the DHCP relay server 172.16.10.2 through the VPN?

Thanks!