Route branch local traffic to Internet via HQ's FGT without VPN ?

[LiaoYuRuei]

Topology:

Hello All, I have the privilege to manage two FGTs.

(I can control NAT, Route... etc on two FGTs.)

Question:

1.Can I route local traffic to 8.8.8.8 via following path ?

   [ Local PC -> FGT1 -> ISP1 -> ISP2 -> FGT2 -> ISP2 -> Internet ]

   In other words, when local PCs visit Internet, they have to go through FGT2 first.

2.If possible, how to implement it?

[rwpatterson · Accepted solution]

Create a VPN and route the traffic across it.

[emnoc · Accepted solution]

Hmm.not so quick.

He mention no  vpn,  but you have another option. GRE-tunnel  the traffic back to the HQ , but keep these thoughts in mind.

[ul]

GRE offers no  protection or encryption.

Any thing that can inspect  1 or 2 level deep will ID the traffic.

PMTUD and max datagram  could be a issues ( UDP is even worst ), you can fixup TCP with mss.tcp adjustments.[/ul]

Overhead with  GRE might be slightly less than ESP encryption from a function and layer3 header

Ken

[ede_pfau · Accepted solution]

I'm afraid that with a static WAN address the next hop (gateway) must be within the same subnet. The scenario I posted will only work if the WAN interface was connecting via PPPoE. Thanks for the KB articles which state this very clearly.

Now IMHO your best bet is to connect site-to-site via SSL VPN in tunnel mode, on a non-standard port, i.e. not 443 but 12345 or such (1023 < port < 65535). If arbitrary traffic is allowed but just not IPsec (udp/500, udp/4500, ESP) this might work.

[rwpatterson]

@LiaoYuRuei Look, I'm not trying to be hard or stubborn, but why are you so resistant to protect your traffic? You are on a firewall forum asking how to send your organization's traffic over the Internet unencrypted so the world can see it? That's like walking around with your pants around your ankles. Doesn't make sense. Setting up a VPN between two Fortigates takes minutes and costs nothing. The potential savings between lost data and stolen information is HUGE. I don't know why you are so hesitant to do what most here would construe as the right thing.

[LiaoYuRuei]

rwpatterson wrote:

@LiaoYuRuei Look, I'm not trying to be hard or stubborn, but why are you so resistant to protect your traffic? You are on a firewall forum asking how to send your organization's traffic over the Internet unencrypted so the world can see it? That's like walking around with your pants around your ankles. Doesn't make sense. Setting up a VPN between two Fortigates takes minutes and costs nothing. The potential savings between lost data and stolen information is HUGE. I don't know why you are so hesitant to do what most here would construe as the right thing.

Hello, rwpatterson,

Yes, you are right, I'm so appreciate for your help.

In fact, the reason that I ask this question is that there is a firewall which I can't control it in the traffic path,

Local PC -> FGT1 -> ISP1 -> [FW, and which I can't control] -> Internet -> ISP2 -> FGT2,

In the past, we used IPSec VPN tunnel as you said, but now the FW block it.

The phenomenon we observed is that (I guess, because I don't have the privilege on firewall):

FW monitor the traffic, if the traffic is used for IPSec VPN, block the IP address with all service.

So, I have to find the way to

1.Control the traffic path as same as the past.

2.To avoid limited IP address which I have being blocked again

(I've lost 1 public IP I can use in the environment.)

[ede_pfau]

Contrary to what the other fellows posted, YES this can be done.

In short: Create a static route on FGT1 with destination FGT2 and use FGT2 as your next hop router.

In more detail:

You want all internet-bound traffic to reach FGT2, and from there, reach the internet. At the moment, the default route in FGT1 ('0.0.0.0/0' in Network > Routing > Static Routes) points to ISP1's router, either 221.27.31.1 or some other destination. Change this gateway to be 59.126.174.2, the FGT2's WAN interface.

technical aside:

You might not find an explicit static default route if FGT1 is connecting via PPPoE or DHCP to ISP1. In this case, you find the default route in Network > Interfaces > WAN1. Un-check "Retrieve default gateway from server" to enable your own default route in Network > Static Routes.

Check that this route is indeed working with a ping to 59.126.174.2. It should work in your current setup, before chaning anything - note the TTL. After setting up the new default route, ping should still work but the TTL will have changed, it will be higher.

Note that a ping to 8.8.8.8 or elsewhere on the internet will NOT work - yet.

Now, FGT2 already knows where to send internet traffic, namely to 59.126.174.1 or some other router in ISP2's control. The only thing missing now is a policy on FGT2 which allows the routing on the WAN1 interface:

create a new policy on FGT2

source interface: WAN1

destination interface: WAN1 (no typo!)

src addr: 221.27.31.2 (FGT1's external public address)

dst addr: ALL

service: ANY

action: ACCEPT

Test this by pinging 8.8.8.8 from LAN1 behind FGT1.

[sw2090]

Well I have plenty times this setup here

FGT1 (here) <-> ISP1 <-> Internet <-> ISP2 <-> FGT2 (shop somewhere)

FGT1 has subnet1 and FGT2 has subnet2 and both have static ip on their wan(s). 

Routing Traffic from here to shop is done via vpn (IPSEC) for our subnet1 and also vor several vlans in both directions.

This works fine so far. 

It should also work with SSL Tunnel and also static ip is not a must have. IF you have no static wan ip you will have to use some dyndns service since you then need a FQDN as remote site to know the opposite wan ip.

In this case just FGT1 needs to know a route to subnet2 if you want to get there and FGT2 needs to know a route to subnet1 to be able to get there.

This works fine here without problems.

IPSEC Tunneling aswell as dyndns is already included in your Fortigates.

I even do it here sometimes over our wlan bridge: We have a shop on the other side of the road that we connect via wlan bridge (because laying a wire into the road cost tons of $$$ unfortunately). They have their own WANs there but if they go down I reroute the internet traffic over the bridge and throughout our wan. There is no vpn here but defined interfaces the bridge is connected to to which one can route.

[emnoc]

I don't see how this will work btw. The ISP1 will make all routing choices based on that destination { 8.8.8.8 in this example }. if what ede discribe would work & with out a VPN tunnel or GRE tunnel, than the 1st question I have is how would  GOOGDNS 8.8.8.8  reply it's dns.answer back &  at a host locate in ISP1 and FGT1? Are we planning on SNAT twice  ( once at FGT1 and a 2nd time at FGT2 ) 

2nd answer what the means gained by doing such thing?

3rd , would latency and number of resources used would be extreme?

Ken

[ede_pfau]

Good points, Ken.

1- yes, the WAN-WAN policy on FGT2 will have to use NAT, so double-NAT here. Otherwise the reply traffic will arrive at ISP1 first which makes for asymmetric routing.

For routing back from FGT2 to FGT1, it only needs a default route to ISP2 as the source address is a public IP.

2- spoil sport :) ! If I have understood the request correctly, OP wants to route internet-bound traffic not through ISP1 (who is filtering) but through ISP2 (who is not). Let me guess, ISP2 is located in a different country...

Now, he needs to be lucky that ISP1 will not look into his not-encrypted traffic...

3- no, why? this is just re-routing. Routing on a FGT doesn't cost much. Latency, yes maybe. Still better than getting filtered.

[LiaoYuRuei]

ede_pfau wrote:

Contrary to what the other fellows posted, YES this can be done.

In short: Create a static route on FGT1 with destination FGT2 and use FGT2 as your next hop router.

In more detail:

You want all internet-bound traffic to reach FGT2, and from there, reach the internet. At the moment, the default route in FGT1 ('0.0.0.0/0' in Network > Routing > Static Routes) points to ISP1's router, either 221.27.31.1 or some other destination. Change this gateway to be 59.126.174.2, the FGT2's WAN interface.

technical aside:

You might not find an explicit static default route if FGT1 is connecting via PPPoE or DHCP to ISP1. In this case, you find the default route in Network > Interfaces > WAN1. Un-check "Retrieve default gateway from server" to enable your own default route in Network > Static Routes.

Check that this route is indeed working with a ping to 59.126.174.2. It should work in your current setup, before chaning anything - note the TTL. After setting up the new default route, ping should still work but the TTL will have changed, it will be higher.

Note that a ping to 8.8.8.8 or elsewhere on the internet will NOT work - yet.

Now, FGT2 already knows where to send internet traffic, namely to 59.126.174.1 or some other router in ISP2's control. The only thing missing now is a policy on FGT2 which allows the routing on the WAN1 interface:

create a new policy on FGT2

source interface: WAN1

destination interface: WAN1 (no typo!)

src addr: 221.27.31.2 (FGT1's external public address)

dst addr: ALL

service: ANY

action: ACCEPT

Test this by pinging 8.8.8.8 from LAN1 behind FGT1.

Hello, ede_pfau

I've ever tried the method you said some days ago,

and the setting on two firewalls are exactly the same just as you said,

but it didn't work because of the default route.

I saw the default route being inactive.

0.0.0.0/0 [10/0] via 59.126.174.2, wan1 inactive

Routing table: (I replaced the real IP with the IP in the topology)

I think the reason why the default route was inactive is which the KB explained.

http://kb.fortinet.com/kb....do?externalID=FD36417

p.s.These two wan1 of the firewalls on topology have their static public IP (not DHCP, PPPoE...etc)

p.s.This method works when establishing Site to Site IPSec VPN between two firewalls, and it is exactly the method what we have ever used in the past.

[ede_pfau · Accepted solution]

I'm afraid that with a static WAN address the next hop (gateway) must be within the same subnet. The scenario I posted will only work if the WAN interface was connecting via PPPoE. Thanks for the KB articles which state this very clearly.

Now IMHO your best bet is to connect site-to-site via SSL VPN in tunnel mode, on a non-standard port, i.e. not 443 but 12345 or such (1023 < port < 65535). If arbitrary traffic is allowed but just not IPsec (udp/500, udp/4500, ESP) this might work.

[LiaoYuRuei]

ede_pfau wrote:

I'm afraid that with a static WAN address the next hop (gateway) must be within the same subnet. The scenario I posted will only work if the WAN interface was connecting via PPPoE. Thanks for the KB articles which state this very clearly.

Now IMHO your best bet is to connect site-to-site via SSL VPN in tunnel mode, on a non-standard port, i.e. not 443 but 12345 or such (1023 < port < 65535). If arbitrary traffic is allowed but just not IPsec (udp/500, udp/4500, ESP) this might work.

Hello,ede_pfau

Sorry that I don't understand "connect site-to-site via SSL VPN in tunnel mode"

Do you mean that each local PC using SSL VPN connect to FGT2?

[ede_pfau · Accepted solution]

Yes, 'site-to-site' is rubbish, sorry. SSLVPN using FortiClient.