Subject: kern/30442: IPSEC tunnel fails to pass traffic in NAT-T mode
To: None <,,>
From: None <>
List: netbsd-bugs
Date: 06/06/2005 14:14:00
>Number:         30442
>Category:       kern
>Synopsis:       ipsec tunnel not passing traffic in nat-t mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 06 14:14:00 +0000 2005
>Originator:     Brett Lymn (Master of the Siren)
>Release:        NetBSD 3.99.5
Brett Lymn
System: NetBSD siren 3.99.5 NetBSD 3.99.5 (SIREN.ACPI.MP) #2: Thu Jun 2 19:46:06 CST 2005 toor@siren:/usr/src/sys/arch/amd64/compile/SIREN.ACPI.MP amd64
Architecture: x86_64
Machine: amd64
	I have a netbsd machine locally and a remote checkpoint firewall,
I am trying to build a site-to-site vpn tunnel between the two using NAT
traversal.  I have previously had this tunnel working fine without NAT
traversal in the mix but changes in my hardware make that setup infeasible
now.  What I am seeing is that that racoon appears to succesfully 
negotiate the tunnel with the checkpoint firewall, if I use "setkey -D" I
can see the SADB entries for the tunnel in the mature state but when I try
to pass traffic over the tunnel tcpdump shows no ESP traffic coming from
the netbsd machine.  If I try access local machines over the tunnel from 
the remote network the checkpoint firewall sends ESP packets to the 
netbsd machine (so, the checkpoint firewall thinks the tunnel is ok).

I am certain my routing is ok - points the tunnel traffic out the
interface connected to the router, I do have ip forwarding on, the traffic
is not being blocked my the adsl router firewall as far as I can tell
(it never seems to leave the interface of the netbsd machine).

	Here are some sanitised (where appropriate) config files:


padding {
	maximum_length 20;
	randomize off;
	strict_check off;
	exclusive_tail off;

listen {
	isakmp [500];
	isakmp_natt [4500];

timer {
	counter 5;
	interval 20 sec;
	persend 1;
	phase1	120 sec;
	phase2	60 sec;

remote anonymous
	#exchange_mode main,aggressive,base;
	#exchange_mode aggressive,main,base;
	exchange_mode main;

	#my_identifier fqdn "";
	#certificate_type x509 "" "" ;

	nonce_size 16;
	lifetime time 1440 min;	# sec,min,hour
	initial_contact on;

	#initial_contact off ;
	#passive on ;

	nat_traversal force;

	# phase 1 proposal (for ISAKMP SA)
	proposal {
		encryption_algorithm 3des;
		hash_algorithm md5;
		authentication_method pre_shared_key ;
		dh_group 5;

	# the configuration makes racoon (as a responder) to obey the
	# initiator's lifetime and PFS group proposal.
	# this makes testing so much easier.
	proposal_check obey;

# phase 2 proposal (for IPsec SA).
# actual phase 2 proposal will obey the following items:
# - kernel IPsec policy configuration (like "esp/transport//use)
# - permutation of the crypto/hash/compression algorithms presented below

sainfo anonymous
	lifetime time 3600 second ;
	encryption_algorithm 3des;
	authentication_algorithm hmac_md5 ;
	compression_algorithm deflate;

(this has been sanitised to protect something...)

# Work VPN
spdadd work.classB.0.0/16 any -P out ipsec esp/tunnel/;
spdadd work.classB.0.0/16 any -P in ipsec esp/tunnel/work.firewall.ip.address-;
spdadd work.firewall.ip.address/32 any -P in ipsec esp/tunnel/work.firewall.ip.address-;
spdadd work.firewall.ip.address/32 any -P out ipsec esp/tunnel/;
spdadd work.classB.0.0/16 any -P in ipsec esp/tunnel/work.firewall.ip.address-;
spdadd work.classB.0.0/16 any -P out ipsec esp/tunnel/;

	Sorry, no clue, I suspect the NAT-T code path but I am not familiar
with the networking guts.