IPSec tunnel not passing traffic to Netgear vpn client

praevidium

Hi. I'm trying to establish an IPSec vpn connection to a pfSense 2.0Beta5 (first Jan 20 build) server with a Netgear client. It appears to succeed but I have no traffic passing through the tunnel to the protected LAN. Nothing I've read so far has helped me. I've also tried connecting with a Shrew Soft 2.1.7 client but get absolutely nowhere. In this case, it seems to fail at or before P1 and reports "network unavailable". The Netgear results below make me wonder if the tunnel is somehow not completely set up even though it appears to be.

If I can get a working tunnel, I intend to move the settings over to an Avaya 4620sw vpn phone for testing. The end goal is to use the pfSense box as a VOIP gateway.

Could someone take a look at the detail below and give me a hand? Thanks.
John

Results with Netgear vpn client 10.8.3 (Build 6) connected:

Status: IPSec page

Local IP = WAN address
Remote IP = blank
Local Network = LAN
Remote Network = Mobile Client
Status = yellow icon
SAD and SPD pages both show associations in both directions with IP addresses as expected.

The IPSec dashboard widget shows the Tunnel Status as inactive.

Firewall rules:
WAN

destination port UDP4500 (IPsec NAT-T) allowed from anywhere to anywhere
destination port UDP500 (ISAKMP) allowed from anywhere to anywhere
destination port ESP allowed from anywhere to anywhere
IPSec
all destination ports allowed from anywhere to anywhere

My local subnet, the vpn client subnet and the protected LAN's subnet are all different.

========= IPSec log =========================================

an 21 01:42:24 racoon: [Public phones]: INFO: unsupported PF_KEY message REGISTER
Jan 21 01:42:24 racoon: [Public phones]: INFO: 75.152.250.47[4500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 75.152.250.47[4500] used as isakmp port (fd=20)
Jan 21 01:42:24 racoon: [Public phones]: INFO: 75.152.250.47[500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 75.152.250.47[500] used as isakmp port (fd=19)
Jan 21 01:42:24 racoon: [Public phones]: INFO: 192.168.43.1[4500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 192.168.43.1[4500] used as isakmp port (fd=18)
Jan 21 01:42:24 racoon: [Public phones]: INFO: 192.168.43.1[500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 192.168.43.1[500] used as isakmp port (fd=17)
Jan 21 01:42:24 racoon: [Public phones]: INFO: 127.0.0.1[4500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 127.0.0.1[4500] used as isakmp port (fd=16)
Jan 21 01:42:24 racoon: [Public phones]: INFO: 127.0.0.1[500] used for NAT-T
Jan 21 01:42:24 racoon: [Public phones]: INFO: 127.0.0.1[500] used as isakmp port (fd=0)
Jan 21 01:42:24 racoon: [Public phones]: NOTIFY: NAT-T is enabled, autoconfiguring ports
Jan 21 01:38:07 racoon: [Public phones]: ERROR: such policy does not already exist: "193.168.43.0/24[0] 192.168.145.5/32[0] proto=any dir=out"
Jan 21 01:38:07 racoon: [Public phones]: ERROR: such policy does not already exist: "192.168.145.5/32[0] 193.168.43.0/24[0] proto=any dir=in"
Jan 21 01:38:07 racoon: [Public phones]: INFO: IPsec-SA established: ESP 75.152.250.47[4500]->70.74.185.113[5780] spi=3602668578(0xd6bc5c22)
Jan 21 01:38:07 racoon: [Public phones]: INFO: IPsec-SA established: ESP 70.74.185.113[5780]->75.152.250.47[4500] spi=258105623(0xf626117)
Jan 21 01:38:07 racoon: [Public phones]: INFO: Adjusting peer's encmode UDP-Tunnel(61443)->Tunnel(1)
Jan 21 01:38:07 racoon: [Public phones]: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jan 21 01:38:07 racoon: [Public phones]: INFO: no policy found, try to generate the policy : 192.168.145.5/32[0] 193.168.43.0/24[0] proto=any dir=in
Jan 21 01:38:07 racoon: [Public phones]: INFO: respond new phase 2 negotiation: 75.152.250.47[4500]<=>70.74.185.113[5780]
Jan 21 01:38:06 racoon: [Public phones]: INFO: ISAKMP-SA established 75.152.250.47[4500]-70.74.185.113[5780] spi:bbc56bfdf8feccc2:e55ce172ec598889
Jan 21 01:38:06 racoon: [Public phones]: INFO: NAT detected: PEER
Jan 21 01:38:06 racoon: [Public phones]: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
Jan 21 01:38:06 racoon: [Public phones]: WARNING: ignore REPLAY-STATUS notification.
Jan 21 01:38:06 racoon: [Public phones]: INFO: NAT-D payload #1 doesn't match
Jan 21 01:38:06 racoon: [Public phones]: INFO: Hashing 70.74.185.113[5780] with algo #2
Jan 21 01:38:06 racoon: [Public phones]: INFO: NAT-D payload #0 verified
Jan 21 01:38:06 racoon: [Public phones]: INFO: Hashing 75.152.250.47[4500] with algo #2
Jan 21 01:38:06 racoon: [Public phones]: INFO: NAT-T: ports changed to: 70.74.185.113[5780]<->75.152.250.47[4500]
Jan 21 01:38:06 racoon: [Public phones]: INFO: Adding xauth VID payload.
Jan 21 01:38:06 racoon: [Public phones]: INFO: Hashing 75.152.250.47[500] with algo #2
Jan 21 01:38:06 racoon: [Public phones]: INFO: Hashing 70.74.185.113[500] with algo #2
Jan 21 01:38:06 racoon: [Public phones]: INFO: Adding remote and local NAT-D payloads.
Jan 21 01:38:06 racoon: [Public phones]: INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
Jan 21 01:38:06 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jan 21 01:38:06 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jan 21 01:38:06 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Jan 21 01:38:06 racoon: [Public phones]: INFO: received Vendor ID: DPD
Jan 21 01:38:06 racoon: [Public phones]: INFO: begin Aggressive mode.
Jan 21 01:38:06 racoon: [Public phones]: INFO: respond new phase 1 negotiation: 75.152.250.47[500]<=>70.74.185.113[500]

========= racoon.conf ========================================

This file is automatically generated. Do not edit

path pre_shared_key "/var/etc/psk.txt";

path certificate "/var/etc";

listen
{
adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
isakmp 75.152.250.47 [500];
isakmp_natt 75.152.250.47 [4500];
}

mode_cfg
{
auth_source system;
group_source system;
pool_size 253;
network4 192.168.145.1;
netmask4 255.255.255.0;
split_network include 192.168.43.0/24;
pfs_group 2;
}

remote anonymous
{
ph1id 1;
exchange_mode aggressive;
my_identifier address 75.152.250.47;

ike_frag on;
generate_policy = on;
initial_contact = on;
nat_traversal = on;

support_proxy on;
proposal_check obey;
passive on;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 86400 secs;
}
}

sainfo anonymous
{
remoteid 1;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
pfs_group 2;
lifetime time 3600 secs;
compression_algorithm deflate;
}

praevidium

Update
1. I was able to connect with the Shrew Soft client by stopping the Netgear-related IPSec services/daemons and manually starting the Shrew IPSec service. Apparently, the Netgear programs had taken the IPSec sockets by default at system startup.

2. I read somewhere that it's too difficult to set the mobile client status so I'm ignoring the IPSec Status page and the widget for now. The SAD's and SPD's do appear to be correct.

3. With the same client configuration in the Shrew client, I can connect and ping the LAN address of the pfSense box (which is in the target protected subnet). I still can't ping any of the other computers in that subnet, though. Their addressing and default gateways are correctly set.

4. Also, I can't seem to get a mobile client address from the pfSense box. I can set it in the client, but the phones will need to be able to get an automatic address.

I've tried all the configurations I've found in posts and elsewhere. Any help would really be appreciated.
John

praevidium

Update
I begin to suspect some misconfiguration on the LAN-side. It's a test environment, so things may not be right there. If anyone could set me right on the mobile client automatic addressing issue, though, I'd appreciate it.
John

praevidium

Update
1. I did indeed find a default gateway misconfiguration on the LAN target computer. It is multi-homed and had two default gateways. I removed the default gateway for the test protected LAN and added a static route to the mobile client virtual subnet from the target computer. I also added a static route to the actual test client subnet, since I haven't been able to get an automatic virtual address yet. These changes did not produce any better results. If anyone is interested, I can post a copy of the routing table.

2. On the virtual address topic, I've tried setting the Shrew client to:
- IKE config pull: no virtual address, but tunnel established
- dhcp over IPSec (even though it is experimental): no virtual address, but tunnel established
- IKE config push: the log says the P1 SA is established, but the Status page says no SADs and no SPDs; the client gets
stuck at "bringing up tunnel"

3. I've read that the mobile client addressing works for others, so it's got to be some misconfiguration somewhere.

eazydor

could you please provide info about your networks. from where to where do you try to connect?

i believe you misconfigured your local network (Phase 2) settings.
you should first try out your configuration i a simple environement for testing purposes.

i suggest you should try to setup a simple connection in a simple environment.
try these: http://forum.pfsense.org/index.php/topic,24752.msg130558.html#msg130558

there must be definetly a fault in your configuration, because setup like yours do work flawlessly.

praevidium

UPDATE
1. I switched over to the Shrew 2.2alpha client and am now getting a virtual address using 'pull IKE config'. That's one down. This was using the pfSense 2.0beta5 Jan24 18:48:13 2011 build.

The IPSec log now shows:

Jan 25 23:06:27 racoon: [Public phones]: ERROR: such policy does not already exist: "192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out"
Jan 25 23:06:27 racoon: [Public phones]: ERROR: such policy does not already exist: "10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in"
Jan 25 23:06:27 racoon: [Public phones]: INFO: IPsec-SA established: ESP 75.152.250.47[4500]->70.74.185.113[42550] spi=238056071(0xe307287)
Jan 25 23:06:27 racoon: [Public phones]: INFO: IPsec-SA established: ESP 70.74.185.113[42550]->75.152.250.47[4500] spi=130373579(0x7c557cb)
Jan 25 23:06:27 racoon: [Public phones]: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jan 25 23:06:27 racoon: [Public phones]: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jan 25 23:06:27 racoon: [Public phones]: INFO: no policy found, try to generate the policy : 10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in
Jan 25 23:06:27 racoon: [Public phones]: INFO: respond new phase 2 negotiation: 75.152.250.47[4500]<=>70.74.185.113[42550]
Jan 25 23:06:21 racoon: [Public phones]: ERROR: Cannot open "/etc/motd"
Jan 25 23:06:21 racoon: [Public phones]: WARNING: Ignored attribute INTERNAL_ADDRESS_EXPIRY
Jan 25 23:06:21 racoon: [Public phones]: INFO: Using port 0
Jan 25 23:06:21 racoon: [Public phones]: INFO: generated policy, deleting it.
Jan 25 23:06:21 racoon: [Public phones]: INFO: ISAKMP-SA established 75.152.250.47[4500]-70.74.185.113[42550] spi:db334ad61daca32c:73f6f0684492a45d
Jan 25 23:06:21 racoon: [Public phones]: INFO: NAT detected: ME PEER
Jan 25 23:06:21 racoon: [Public phones]: INFO: NAT-D payload #1 doesn't match
Jan 25 23:06:21 racoon: [Public phones]: INFO: Hashing 70.74.185.113[42550] with algo #2
Jan 25 23:06:21 racoon: [Public phones]: INFO: NAT-D payload #0 doesn't match
Jan 25 23:06:21 racoon: [Public phones]: INFO: Hashing 75.152.250.47[4500] with algo #2
Jan 25 23:06:21 racoon: [Public phones]: INFO: NAT-T: ports changed to: 70.74.185.113[42550]<->75.152.250.47[4500]
Jan 25 23:06:21 racoon: [Public phones]: INFO: Hashing 75.152.250.47[500] with algo #2
Jan 25 23:06:21 racoon: [Public phones]: INFO: Hashing 70.74.185.113[500] with algo #2
Jan 25 23:06:21 racoon: [Public phones]: INFO: Adding remote and local NAT-D payloads.
Jan 25 23:06:21 racoon: [Public phones]: INFO: Selected NAT-T version: RFC 3947
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: CISCO-UNITY
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: RFC 3947
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
Jan 25 23:06:21 racoon: [Public phones]: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jan 25 23:06:21 racoon: [Public phones]: INFO: begin Aggressive mode.
Jan 25 23:06:21 racoon: [Public phones]: INFO: respond new phase 1 negotiation: 75.152.250.47[500]<=>70.74.185.113[500]

The ERROR: Cannot open "/etc/motd" is apparently because /etc/motd doesn't exist. I don't know if this affects anything else, but the virtual address is indeed assigned from the expected pool.

2. I had no confidence in using the original multi-homed target computer in the protected LAN, so I installed another one using a single network connection. Unfortunately, I still cannot ping that one either through the tunnel.

praevidium

The setup is basic: test client -> NAT router (pfSense 1.2.3) -> internet cloud -> test pfSense box (2.0beta5) -> test LAN.

As noted above, my one remaining issue is the lack of traffic. The racoon.conf file has not changed with the exception of:
'split_network include 192.168.43.0/24;' which is now gone. I haven't made any manual changes through the web interface in days now, so I don't know how this happened; maybe through an upgrade.

I also notice now that the compression_algorithm is set to 'deflate'. I don't see anywhere that can be set in this current build, but I could have sworn I saw it in an earlier one. The SS client default is 'disable'. I'll see if that has any effect on my problem.

praevidium

UPDATE
1. When I set the SS client P2 compression algorithm to 'deflate' to match the server setting, the client hangs at 'bringing up tunnel…' and no SADs or SPDs are established. The IPSec log says 'WARNING: Short payload'. I also note that the server setting cannot be changed by editing the racoon.conf file. I can't tell if this affects my traffic problem directly or not.

praevidium

CONCLUSION

As a last 'hail mary pass', I decided to re-install pfSense 2.0 from a cd instead of using the 1.2.3 upgrade that was in place. Within a few minutes, I had the IPSec mobile client tunnel configured and had connectivity to the protected LAN with a Shrew Soft client. I can't say why. I used all the same IPSec parameters on the server and didn't touch the client parameters at all.

Here are some other things I learned along the way:

1. UDP500 outbound NAT must be statically mapped. Since this is now automatically generated, it is not an issue.

2. The IPsec implementation does not support multi-WAN failover, and gateway failover groups cannot be used in IPSec firewall rules. This is unfortunate. Giving it WAN failover functionality would make pfSense an excellent replacement for the Netgear FVS336G Dual WAN VPN Gateway my customer is trying to move away from.

3. SDPs can have mismatched ports after a change to the IPSec configuration. This will prevent traffic from passing through the tunnel. Restarting racoon clears this up, but is cumbersome.

4. Even though the Shrew Soft client works, the Netgear client still can't obtain an automatic virtual address. However, if configured to, it can request and obtain a specific one. Nonetheless, even though it and the server report an established tunnel, there is no connectivity with the server's LAN address or any computer in the LAN. I'm abandoning the effort, though. My goal is a working IPSec tunnel with an Avaya 4620SW IP phone. The software client was only intended as a breadboard and the Shrew Soft client has obliged.

I'll open up a new thread with regard to the phone tests.