Question about IPsec's Phase Two Addressing

[CoreyFP]

Points to ponder:

1.) I have successfully established a functional IPsec tunnel between a Fortigate 200E and a pfSense virtual machine.

2.) I noticed that in Phase 2, if I have the Fortigate's local address set to 0.0.0.0/0 and the pfsense's remote address set to 0.0.0.0/0, I understand that to mean all traffic from the pfsense end of the tunnel will now route through the Fortigate. With this, there's full connectivity and both networks can see each other's devices, no problem. Except the fact my boss doesn't want EVERYTHING coming from pfsense through the Fortigate.

3.) Now, if I change the 0.0.0.0 to reflect the Fortigate's LAN subnet on both ends, the pfSense now only routes packets destined for the Fortigate's network through the tunnel and routes all public traffic through it's own WAN interface. This fulfills my boss's wishes! But now the Fortigate has no detection of any devices on the pfSense LAN side. PfSense is the only side that can see through to the remote end of the tunnel.

Two Questions:

1.) Does anyone know why when Phase Two is set up to point #3's configuration, the Fortigate can now no longer see traffic coming in from the pfSense end of the IPsec tunnel, when it could when it was set up to point #2's standard? I would like to understand this better.

2.) Is there a static route or a forwarding rule that will still allow the Fortigate to see everything on the pfSense network even with point #3's setup?

[CoreyFP]

I guess no one knows? All I want to know is the science behind the phase 2 address. What is the science behind using a 0.0.0.0 address versus the specific subnet of device where all the traffic is being routed through it (or some of it). Why Site A and Site B can both see each other if it's 0.0.0.0 and why Site A can see Site B, but Site B can't see Site A when there's a specific subnet. Anyone? Beuller? Beuller?

[emnoc]

Pfsense and raccoon should have  set left/right subnets. Do not use 0.0.0:0/0 in your examples you see why.

Review this post thread

https://forum.fortinet.com/tm.aspx?m=119677

Also double check fwpolicy creation in  pfsense webGUi to ensure you have the correct policies and for the IPsec-action.

Ken

[CoreyFP]

I had found out the issue with Fortigate support.

The agent had me run "diag sniff packet any 'host x.x.x.x and y.y.y.y (or icmp)' 4" to see what was happening with the packets as they left pfsense and moved through the Fortinet. 

Upon closer inspection, we saw that in the IPv4 Policies NATing was enabled on the IPv4 rules between the tunnels.

Of course, NATing isn't necessary between two private addresses, so, disabling that opened up communication between the two firewalls.

I both love and hate it when it's that simple...

[emnoc]

the cli cmd diag debug  flow is your best friend

[ede_pfau]

Beuller here!

The Quick Mode selectors in phase2 only determine which traffic can initiate a session across the tunnel. They do not determine routing or accept/deny rules. That is left to the corresponding static routes and the policies.

Secondly, in FortiOS, '0.0.0.0/0' is either a placeholder (e.g. in interface config), or a wildcard (e.g. in phase2 QM or in routes). With IPsec VPN this meta-address is meant to faciliate setting up a FGT-to-FGT tunnel. Regardless of the subnets on both LANs, using the wildcard will ensure the tunnel is negotiated. Traffic policying then is done with the help of policies.

Things  may be different on the pfSense side. If I understood it correctly, using the null mask in phase2 automatically creates a default route to the tunnel. This is seperated in FortiOS.

Using NAT in the tunnel policies makes for fun in troubleshooting. Here, it crucially depends on the sequence of applying NAT and the QM selectors whether traffic is opening the tunnel or not. In my understanding, NAT in the policy at the local end (LAN to tunnel) will be applied first; the QM selectors should deal with the NATted address range as source network. But frankly, as I never had to use NAT in a tunnel I am not 100% sure about this (of course, 'diag deb flow is your friend').

To get back to the questions:

- check not only the QM selectors but the tunnel state as well while experimenting; be sure all SAs are deleted before you test a change

- you need one static route per remote subnet, on each side

- best practice says to always fill the QM selectors explicitly with the subnets that are joined by the tunnel