>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
>Organization:
Brett Lymn
>Environment:
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
>Description:
	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).

>How-To-Repeat:
	Here are some sanitised (where appropriate) config files:

racoon.conf:


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

listen {
	isakmp 192.168.3.1 [500];
	isakmp_natt 192.168.3.1 [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 "server.kame.net";
	#certificate_type x509 "foo@kame.net.cert" "foo@kame.net.priv" ;

	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;
}


/etc/ipsec.conf:
(this has been sanitised to protect something...)

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

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