[IPSEC site-to-site] Subnets Connectivity
-
@nomatter
Freebsd does not always work correctly on a virtual machine. In particular, IP packet checksums are not always correctly calculated by network card drivers . Try to enable this option
/System/Advanced/Networking -
@nomatter said in [IPSEC site-to-site] Subnets Connectivity:
Shouldn't they have dest address 172.19.5.219?
Only if that is where the ping initiated from, but I suspect that there might be some confusion from the configuration of the VPN.
In the IPSEC Phase 2, it is possible to configure it to ping a remote destination to keep the tunnel up. In this case it will ping from 172.16.17.30 to that remote destination, which will be replying, I suspect this is what you are actually seeing. -
Enabled but nothing significant happens.
There was misconfiguration on AWS VPC Routing table layer that's why I couldn't ping 172.16.17.30 which is pfsense's VTI.
Now I'm able to ping 172.16.17.30 from 172.19.5.219Should I be able to ping 172.16.17.29 which is remote tunnel endpoint? 172.16.17.28/30 is directly attached to pfsense so if i understand correctly in normal circumstances I should be able to ping 172.16.17.29 from any host in 172.19.5.0/24
For now I can not.
Is it normal? -
@awebster
I don't have checkmark on "automatically ping host" in Phase 2 settings but nevertheless there is ICMP traffic between 172.16.17.30 and 172.16.17.29 all the time and it's not related to my ICMP requests from host in private subnet.tcpdump -nni ipsec2000 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ipsec2000, link-type NULL (BSD loopback), capture size 262144 bytes >>>07:41:53.453287 IP 172.16.17.30 > 192.168.179.117: ICMP echo request, id 64007, seq 16, length 64 07:41:53.668029 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 5860, seq 13119, length 8 07:41:53.668077 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 48500, seq 54233, length 8 >>> 07:41:53.732895 IP 192.168.179.117 > 172.16.17.30: ICMP echo reply, id 64007, seq 16, length 64] 07:41:53.947746 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 5860, seq 13119, length 8 07:41:53.947762 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 48500, seq 54233, length 8 07:41:54.209324 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 48500, seq 54234, length 8 07:41:54.209372 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 5860, seq 13120, length 8 >>> 07:41:54.453365 IP 172.16.17.30 > 192.168.179.117: ICMP echo request, id 64007, seq 17, length 64 07:41:54.488891 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 48500, seq 54234, length 8 07:41:54.488906 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 5860, seq 13120, length 8 07:41:54.724422 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 5860, seq 13121, length 8 07:41:54.724473 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 48500, seq 54235, length 8 >>> 07:41:54.733203 IP 192.168.179.117 > 172.16.17.30: ICMP echo reply, id 64007, seq 17, length 64 07:41:55.004501 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 5860, seq 13121, length 8 07:41:55.004517 IP 172.16.17.29 > 172.16.17.30: ICMP echo reply, id 48500, seq 54235, length 8 07:41:55.265786 IP 172.16.17.30 > 172.16.17.29: ICMP echo request, id 48500, seq 54236, length 8
-
Should I be able to ping 172.16.17.29 which is remote tunnel endpoint?
@nomatter, you will not be able to ping 172.16.17.29 from 172.19.5.0/24 subnet because the C3945 doesn't know how to get back to 172.19.5.0.
-
So I if understand you correctly, you 100% sure that issue is caused by missing routes on the other side?
And there is no possibility that I missed something in configuration on my side? -
@nomatter 100%
-
@awebster
So other side refused to set routes for my private network :) They say that's my private network should be NATed to virtual tunnel endpoint. And it's working like that for all other parties.I've set lab environment with ipsec tunnel between 2 pfSenses.
Of course we need routes on both sides with opposite virtual IPs and endpoints. That's confirmed.
Everything is working between 2 pfsenses until...Turned that there is another issue:
When trying to apply Outbound NAT on VTI interface connectivity between hosts in remote private networks is lost.
And I have exactly the same situation which was discussed previously in this topic:
ICMP replies are getting back to VTI interface but don't going further to source host.Are there any issues or limitations with outbound NAT to VTI in pfsense?
-
Summary:
- For unknown reason src-nat doesn't work properly with VTI. Observed behavior is described above.
- Routed VTI can be used and everything is ok without using NAT to tunnel interface. Setup is simple. Netgate even has video on this.
- My issue was solved using software (infrastructure is in AWS) from another vendor.
-
@nomatter Thanks for the followup.
I've not experimented with VTI source NAT before, and I'm surprised to see that it doesn't in fact work.