IPSEC Mobile VPN return route issue

nought

I'm having an issue with a IPSC 'Road Warrior' set up. The VPN comes up and traffic flows from the remote client to the 'Inside Box' but return traffic is not reaching the 'Remote Client'. Can anyone advise no whether a return route is required and how this would be set up?

The VPN address pool is 192.168.240.0/24

WireShark running on the 'Inside Box' shows icmp and http being received from the 'Remote Client' (VPN Connected) and replies being sent, but the 'Remote Client' never seems to receive the replies.

Ping from 'Remote Client' of 'Inside Box' returns 'request timed out.'

Ping from 'Inside Box' of 'Remote Client' returns 'Reply from 192.168.230.1: Destination host unreachable.'

I have read several 'Road Warrior' tutorials and none mention the need to set up a return route to the VPN address pool subnet. Has anyone else seen this problem or does anyone know how to fix it?

I should mention that I have set this up in a lab after having the issue on my production systems, thus the private ip ranges on the outside. Also there are 2 optional LANs also configured on the pfSense box.

I can post details of the VPN configuration if that helps, but as the VPN is coming up and traffic is flowing in one direction I'm thinking the issue is not with the VPN phase 1, phase2, etc…

Thanks,
nought.

Rural

Hi Nought,

I think we are in the same boat. I'm seeing very similar behaviour.

As far as I can tell, I'm not doing anything out of the ordinary. Just a Windows machine running Shrew to a pfSense box. Pings from the Windows workstation to a Linux workstation on the pfSense LAN fail.

kdavidhall

I'm seeing the same problem at Nought. I am pinging from a remote machine running Cisco/Shrew clients. Using WireShark I can see the Echo Request arrive at the inside machine and can see the Echo Replies going out. Further, at the pfSense I can see both the Echo Requests and Echo Replies in the Packet Trace on the LAN interface. This means that the Echo Replies are making it to the pfSense box, but then they disappear.

I have further gone through some experiments of adding various PASS or BLOCK rules with logging turned on in an attempt to track down what pfSense is doing with these packets. At this point it would appear as if they are being silently dropped at the LAN interface.

Another point of concern in this configuration that I have not seen mentioned anywhere is that on a Cisco ASA you have to explicitly prevent VPN traffic from being translated by NAT. I have attempted to do this on this pfSense configuration, but still no joy.

Thoughts?

-kdh

Obliv10n

Hi guys,

Any development on the issue ?
I'm experiencing the same problems with a typical setup. Shrew and Cisco VPN client used.
Manual NAT doesn't seem to help either.

I thought it was something introduced with the latest build (2.0.1), but seeing you have the same problems with 2.0.0 also, it's now out of the equation.

Any devs out there with a clue ?

Regards,

O.

nought

No, I haven't managed to crack this yet and, unfortunately, I'm getting to the stage where I've really tried everything I can think of.

I agree that it seems replies are getting back to the firewall but then are not being placed back on the VPN tunnel. Nothing is showing up in the security logs so this would seem to be a routing issue rather then a ACL/Rule problem?

The fact that it's happening on both Shrew and VPN clients also leads me to think it's an issue at the firewall (although I guess it could be the same misconfiguration of both clients)?

I did try giving the remote client an IP on the inside network but this also didn't help.

Crusnik01

Hmm.. I might have somewhat of the same problem…

When the IKE packet arrives at the external interface, absolutely nothing happends on the IPsec side.

I see the packet in tcpdump, the firewall accepts (allows) it, and then nothing.

Racoon does not log anything, tcpdump doesn't show any packets going back, it just dies.

I have no idea how to troubleshoot this. I've tried running racoon in debug mode, but again, nothing is show after it starts and the packet arrives.

The setup is as standard as it can get, I think, so yeah... Any tips?

EDIT: Thought I'd just test connecting with Shrew Soft VPN client from my PC on the internal network, and that actually worked. Not that I'm much wiser now because of that discovery. :/

Crusnik01

Known issue, as it turns out:

http://redmine.pfsense.org/issues/1351

kdavidhall

So how can we help to nail down the source of this problem? I've gotten a little more knowledgeable since my last post, but I'm still not completely there. If my understanding is correct a packet entering the LAN interface would be sent to racoon at some point to see if it matches any of the SPDs. If it does, racoon sends the packet into the appropriate tunnel. If not, it should pass the traffic on through the normal process.

If this is a correct understanding then the packets in question are disappearing inside pfSense because racoon is for some reason silently dropping the packets rather than doing what it is supposed to do.

It seems that there would be two possible causes of this problem:

1. These packets are being translated by NAT before they are sent to racoon, which would cause them not to match any SPDs.

2. There is some subtle error in racoon that causes it to not see the match - perhaps because of a logic error regarding the 0.0.0.0/0 specifier in the SPD.

If someone will point me in the right direction, I will read and/or instrument the code and see if I can find the problem.

One other question: Does anybody know if there is any way to turn on logging for NAT rules. This would be helpful also in understanding packet flow inside pf.

Thanks.

-Dave