The issue has been resolved. I was using ip addresses that were in my list of virtual ip addresses as well. After removing them from the virtual list it works like a charm!
On 9 February 2018 at 15:25, Mark Wiater <[email protected]> wrote: > > > On 2/9/2018 6:42 AM, Roland Giesler wrote: > >> Ok, I'll try again with real (fake) addresses to make it better >> understood. >> >> WAN gateway: 197.212.127.194 (primary firewall interface), next hop >> gateway 197.212.127.193 >> >> Phase1: >> >> Interface: Virtual IP 41.22.123.70 >> >> Phase2: >> >> Local address: address 192.168.110.130 >> Local NAT translation: address 41.22.123.70 >> >> Remote address: 196.210.117.67 (A public ip) >> >> When phase1 and 2 are up and connected, I see no route for 196.210.117.67 >> in the routing table. >> >> Doing a traceroute from 192.168.110.130, I get traffic leaving the network >> via 197.212.127.193, not via 41.22.123.70. This could be because >> 41.22.123.70 is just a virtual address though, or what? It may not be >> meaningful after all. >> >> In the firewall log I see: >> Feb 8 18:07:40 â–º IPsec >> <https://in.gtst.xyz/easyrule.php?action=block&int=ipsec&src >> =41.75.111.178&ipproto=inet >> <https://mailtrack.io/trace/link/353296e0fd669efd7c862ce29e7663e1780f1647?url=https%3A%2F%2Fin.gtst.xyz%2Feasyrule.php%3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%26ipproto%3Dinet&userId=977006&signature=5461b84f49a7291f> >> > >> 41.22.123.70:57914 >> <https://mailtrack.io/trace/link/c30452f14c6d4a5cb6e3e7c1a63370eb07785153?url=http%3A%2F%2F41.22.123.70%3A57914&userId=977006&signature=8723c0c4a107129a> >> <https://in.gtst.xyz/easyrule.php?action=pass&int=ipsec&prot >> o=tcp&src=41.75.111.178&dst=196.201.107.67&dstport=21410&ipproto=inet >> <https://mailtrack.io/trace/link/b3482777c2a8a70cb4fede2b041835060fd0381d?url=https%3A%2F%2Fin.gtst.xyz%2Feasyrule.php%3Faction%3Dpass%26int%3Dipsec%26proto%3Dtcp%26src%3D41.75.111.178%26dst%3D196.201.107.67%26dstport%3D21410%26ipproto%3Dinet&userId=977006&signature=520d060d64cc065f> >> > >> 196.210.117.67:12345 >> <https://mailtrack.io/trace/link/531caa74e94d70566fed457c0d5b0ce520dd711f?url=http%3A%2F%2F196.210.117.67%3A12345&userId=977006&signature=f252e0bea96656e6> >> TCP:S >> So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67, >> but I'm not getting any response from the remote. >> >> Is this wrong? If so, what is right? I cannot expose the LAN ip address >> to the tunnel (192.168.110.130), I need to use the public IP... >> >> thanks again >> >> >> > In my experience, one does not see routes in the routing table for IPSEC > based routes. > > IPSEC tunneling, I believe, happens before any NATting might. This might > be why you're seeing your traffic exit the default gateway since it still > possesses it's original ip addresses. I'm not sure what you are trying to > achieve is possible on the same device, unless you do some kind of NAT on > the incoming interface if that's possible. > > Seeing actual configuration files might be helpful. So would the results > of packet capture on both I{SEC interfaces. > > Mark > > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > <https://mailtrack.io/trace/link/924383774a6f97a761e10b93c0572f23ddca274b?url=https%3A%2F%2Flists.pfsense.org%2Fmailman%2Flistinfo%2Flist&userId=977006&signature=340f46c224de5ac2> > Support the project with Gold! https://pfsense.org/gold > <https://mailtrack.io/trace/link/cf3d3c2f2c3a9c57b52bf6dd18b4e32dfdfc0072?url=https%3A%2F%2Fpfsense.org%2Fgold&userId=977006&signature=ff31344544dc636f> > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
