Packets destined for IPSEC tunnell go through NAT instead…

rjohanneson

We've setup an instance of pfSense-1.2-RC3 to act as a VLAN router/firewall and IPSEC vpn concentrator. We've been able to establish an IPSEC tunnel from point A to point B. Problem is, no traffic flows through the tunnel unless it's from the remote network to pfSense itself. Currently, for testing, all traffic is allowed on the IPSEC interface, and the one of the VLANs (10.0.0.0/24).

So, if you (from the remote site, 10.1.1.0/24) ping the pfSense VLAN10 local IP (10.0.0.1), you receive a response.
If you ping the remote site (10.1.1.1 for example) from pfSense, or any host on the local networks, you get no response.

After doing so, if you look at the state table, pfSense is attempting to NAT the second ping attempt. Lists something like 10.0.0.2 -> public ip -> 10.1.1.1

A little more on the network setup:

Dell 3448 Layer 3 switch, pfSense connected to port configured in trunk mode.
Three VLANs in place, VLAN 10 (10.0.0.0/24), VLAN 20 (10.0.1.0/24) VLAN 30 (10.0.2.0/24)
Remote site local subnet 10.1.1.0/24

pfSense has 3 optional interfaces, one for each vlan.
VLAN10 IP -> 10.0.0.1 - configured as LAN
VLAN20 IP -> 10.0.1.1 - configured as OPT1
VLAN30 IP -> 10.0.2.1 - configured as OPT2

There are no LAN interfaces that are untagged; topics and postings I've read seem to indicate this is the best way to set things up (i.e. Physical network card for LAN doesn't have any assignments, only the three optional VLAN interfaces do.)

Remote VPN Device is a linksys RV042 VPN router.

There are also some port forwards in place for a web server and another in-house application. Automatic outbound NAT is currently enabled.

Anyone have any suggestions?

Thanks!

sullrich

My suggestion is to open up the rules and start to slowly clamp them down ensuring that everything still works. Also search the forum concerning the way pfSense treats incoming packets. Hint: you need to permit traffic to the other end of the tunnel on the incoming interface as well (LAN, etc)

rjohanneson

We've got an 'allow anything' on the LAN interface (VLAN 10) and an 'allow anything' rule on the IPSEC interface on pfSense. If I do a tcpdump on enc0 and ping a host on the LAN subnet from the other end of the ipsec tunnell (10.1.1.0/24), I see the incoming ping request, and the outgoing ping response, but the remote network never receives the packet. I've also checked the filters on the remote linksys router, and I'm not having much luck. We've even tried dropping the filters on the remote end entirely, and still no response.

In my initial look at the state table I wasn't quick enough. An initial attempt to go directly to the host w/o involving NAT happens, and then after some time, NAT gets involved. I also have the system logging all blocked packets, and I don't see any blocks of my ICMP packets being logged.

If I see the incoming request, and the pinged host's response on enc0, that seems to indicate that the filters on pfSense aren't in play, unless the outbound ping response is getting filtered out somewhere and I'm just not finding it. I've got the exact same setup working on v1.0.1, so I'm really not sure why this isn't working on the new version. Has the handling of packets destined to IPSEC tunnels changed in 1.2 beyond the IPSEC interface filters? I'm really baffled by this one….

Thanks again for any insight you can offer on this one.