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 <mark.wia...@greybeam.com> 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

Reply via email to