Solved [SOLVED] IPSEC/L2TP VPN on 10.0, no traffic to internet

Hello

I want to set up a freebsd IPSEC/L2TP road-warrior vpn server. I want to use it when I'm on untrusted networks to send all my traffic over.

I have it set up so that a Mac OS X 10.9 client can connect to the vpn using PSK and username+password. The VPN itself connects without issues. However, it cannot access the internet, the traffic won't leave the VPN. When the VPN is disabled, "internet" is accessible again.

I'm running FreeBSD 10.0-RELEASE on a vps (xen-hvm). I'm using racoon and mpd5. I've compiled a new kernel based on GENERIC with the following extra options:
Code:
	# VPN
	options         IPSEC
	options         IPSEC_NAT_T
	device          crypto
	device          enc

	# Firewall & NAT for VPN
	options         IPSEC_FILTERTUNNEL
	options         IPFIREWALL
	options         IPFIREWALL_NAT
	options         IPFIREWALL_VERBOSE
	options         IPFIREWALL_VERBOSE_LIMIT=5
	options         LIBALIAS
	options         IPDIVERT

I've installed ipsec-tools and mpd5 from ports and applied the following patch to racoon for wildcard support:

Code:
	diff -rup srca/racoon/localconf.c srcb/racoon/localconf.c
	--- src/racoon/localconf.c 2014-03-29 11:17:32.000000000 +0200
	+++ src/racoon/localconf.c 2014-03-29 11:18:09.000000000 +0200
	@@ -207,7 +207,8 @@ getpsk(str, len)
	 		if (*p == '\0')
	 			continue;	/* no 2nd parameter */
	 		p--;
	-		if (strncmp(buf, str, len) == 0 && buf[len] == '\0') {
	+		if (strcmp(buf, "*") == 0 ||
	+			(strncmp(buf, str, len) == 0 && buf[len] == '\0')) {
	 			p++;
	 			keylen = 0;
	 			for (q = p; *q != '\0' && *q != '\n'; q++)

Here's my /usr/local/etc/racoon/racoon.conf:

Code:
	listen
	{
	        isakmp           external_vps_ip [500];
	        isakmp_natt      external_vps_ip [4500];
	        strict_address;
	}
	remote anonymous
	{
	        exchange_mode    main;
	        passive          on;
	        proposal_check   obey;
	        support_proxy    on;
	        nat_traversal    on;
	        ike_frag         on;
	        dpd_delay        20;
	        proposal
	        {
	                encryption_algorithm  aes;
	                hash_algorithm        sha1;
	                authentication_method pre_shared_key;
	                dh_group              modp1024;
	        }
	        proposal
	        {
	                encryption_algorithm  3des;
	                hash_algorithm        sha1;
	                authentication_method pre_shared_key;
	                dh_group              modp1024;
	        }
	}
	sainfo anonymous
	{
	        encryption_algorithm     aes,3des;
	        authentication_algorithm hmac_sha1;
	        compression_algorithm    deflate;
	        pfs_group                modp1024;
	}

/usr/local/etc/racoon/setkey.conf:

Code:
	flush;
	spdflush;
	spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in  ipsec esp/transport//require;
	spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;

/usr/local/etc/mpd5/mpd.conf:

Code:
	startup:
	        set user super pwSuper admin
	        set console self 127.0.0.1 5005
	        set console open
	        set web self 127.0.0.1 5006
		set web user admin pwSuper
	        set web open
	default:
	        load l2tp_server
	l2tp_server:
	        set ippool add pool_l2tp 192.168.99.30 192.168.99.100
	        create bundle template B_l2tp
	        set iface enable proxy-arp
	        set iface enable tcpmssfix
			set iface route default
	        set ipcp yes vjcomp
	        set ipcp ranges 192.168.99.0/24 ippool pool_l2tp
	        set ipcp dns 8.8.8.8
	        create link template L_l2tp l2tp
	        set link action bundle B_l2tp
	        set link enable multilink
	        set link no pap chap eap
	        set link enable chap
	        set link keep-alive 0 0
	        set link mtu 1280
	        set l2tp self external_vps_ip
	        set l2tp enable length
	        set link enable incoming

/etc/sysctl.conf:

Code:
	net.pfil.forward=1
	net.inet.ip.forwarding=1
	net.inet6.ip6.forwarding=1

/etc/rc.conf:

Code:
hostname="vps.domain.ext"
	ifconfig_re0="DHCP"
	ifconfig_xn0="DHCP"
	ifconfig_xn0_ipv6="inet6 accept_rtadv"
	ifconfig_re0_ipv6="inet6 accept_rtadv"
	sshd_enable="YES"
	ntpd_enable="YES"
	dumpdev="AUTO"
	nginx_enable="YES"
	linux_enable="YES"
	firewall_enable="YES"
	firewall_script="/etc/rc.firewall"
	firewall_type="OPEN"
	firewall_quiet="NO"
	firewall_logging="YES"
	ipsec_enable="YES"
	ipsec_program="/usr/local/sbin/setkey"
	ipsec_file="/usr/local/etc/racoon/setkey.conf"
	racoon_enable="YES"
	racoon_flags="-l /var/log/racoon.log"
	mpd_enable="YES"
	pf_enable="YES"
	pf_rules="/etc/pf.conf"
	pflog_enable="YES"
	pflog_logfile="/var/log/pflog"
	gateway_enable="YES"

/etc/pf.conf:

Code:
	ext_if = "xn0"
	vpn_net = "{192.168.99.0/24}"
	nat on $ext_if inet from $vpn_net to any -> $ext_if
	pass in on $ext_if inet proto udp from any to (self) port { 1701, 500, 4500 }
	pass in on $ext_if inet proto esp
	pass quick on ng0 all
	pass quick on ng1 all
	pass quick on ng2 all
	pass quick on ng3 all
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

I'm confused about both IPFW being build into your kernel and enabled in your rc.conf in addition to using pf. Are you sure there's no conflicts between the two?

What have you done to troubleshoot? I haven't used IPSEC or L2TP so I can't offer anything specific to that. A sanity check of the configs looks fine. Can you at least see that data is getting from the client and back on the external interface?
tcpdump -i xn0 proto esp
or
tcpdump -i xn0
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

I followed an earlier article which first enables IPFW and later on gives PF rules (http://wiki.stocksy.co.uk/wiki/L2TP_VPN_in_FreeBSD).

I've connected multiple VPN clients (Android 4.4, OS X 10.9, Windows 7, iPad iOS 7) and all of them, when tunneling all traffic over the vpn (as in, changing the default route) stop being able to connect to the internet. The traffic from and to the VPS works, because on the VPS VPN IP (192.168.99.1) I see the VPS website. When not tunneling all traffic over the VPN, it also shows the VPS website on the IP of the VPN.

Here is output from "tcpdump -i xn0", while connecting a OS X client to the VPN:

Code:
22:12:51.567345 IP 77-172-73-184.ip.telfort.nl.isakmp > vps4.sparklingclouds.nl.isakmp: isakmp: phase 1 I ident
22:12:51.569632 IP vps4.sparklingclouds.nl.isakmp > 77-172-73-184.ip.telfort.nl.isakmp: isakmp: phase 1 R ident
22:12:51.774094 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: NONESP-encap: isakmp: phase 1 I ident[E]
22:12:51.774645 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: NONESP-encap: isakmp: phase 1 R ident[E]
22:12:51.800856 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: NONESP-encap: isakmp: phase 2/others R inf[E]
22:12:52.648101 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
22:12:52.648732 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
22:12:52.998056 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
22:12:52.999916 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1), length 132
22:12:53.182701 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x1), length 164
22:12:53.626346 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x2), length 68
22:12:53.627863 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x3), length 84
22:12:53.628319 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x2), length 84
22:13:11.832627 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: NONESP-encap: isakmp: phase 2/others R inf[E]
22:13:12.108666 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: NONESP-encap: isakmp: phase 2/others I inf[E]
22:12:53.973984 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x4), length 132
22:12:53.976873 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x5), length 100
22:12:53.977935 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x3), length 100
22:12:53.978071 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x6), length 84
22:12:53.979380 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x4), length 84
22:12:56.266301 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x7), length 68
22:12:56.266803 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x7), length 100
22:12:56.485910 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x8), length 84
22:12:56.486403 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x8), length 84
22:12:56.487075 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x9), length 68
22:12:56.487251 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0x9), length 84
22:12:56.734065 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0xa), length 132
22:12:56.775153 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0xa), length 116
22:12:56.901305 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0xb), length 84
22:12:57.011120 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0xb), length 84
22:12:57.011493 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0xc), length 84
22:12:57.013058 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0xc), length 84
22:12:57.013372 IP vps4.sparklingclouds.nl.sae-urn > 77-172-73-184.ip.telfort.nl.sae-urn: UDP-encap: ESP(spi=0x01b1592e,seq=0xd), length 84

[...]

22:12:57.612107 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x11), length 148
22:12:57.612274 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 63984+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:12:57.615009 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x12), length 148
22:12:57.615142 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 21663+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:12:57.616952 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x13), length 148
22:12:57.617101 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 43163+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:12:57.620095 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x14), length 116
22:12:57.620243 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 35048+ A? sublimetext.com. (33)
22:12:57.622341 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x15), length 132
22:12:57.622504 IP 192.168.99.30.52938 > google-public-dns-a.google.com.domain: 63866+ A? www.isg-apple.com.akadns.net. (46)
22:12:57.624005 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x16), length 148
22:12:57.624108 IP 192.168.99.30.65326 > google-public-dns-a.google.com.domain: 3431+ A? 1.courier-push-apple.com.akadns.net. (53)
22:12:57.627096 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x17), length 148
22:12:57.627197 IP 192.168.99.30.61250 > google-public-dns-a.google.com.domain: 55724+ A? 1-courier.sandbox.push.apple.com. (50)
22:12:57.628974 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x18), length 116
22:12:57.629069 IP 192.168.99.30.62641 > google-public-dns-a.google.com.domain: 59719+ A? ponify.nl. (27)
22:12:57.631977 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x19), length 132
22:12:57.632158 IP 192.168.99.30.58645 > google-public-dns-a.google.com.domain: 57886+ A? radarsubmissions.apple.com. (44)
22:12:57.752060 IP 77-172-73-184.ip.telfort.nl.49611 > vps4.sparklingclouds.nl.snpp: Flags [.], ack 7516, win 8181, options [nop,nop,TS val 796088203 ecr 1482740083], length 0
22:12:57.773383 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1a), length 148
22:12:57.773577 IP 192.168.99.30.52437 > google-public-dns-a.google.com.domain: 46352+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:12:57.776474 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1b), length 148
22:12:57.776616 IP 192.168.99.30.62989 > google-public-dns-a.google.com.domain: 20254+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:12:57.779057 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1c), length 148
22:12:57.779172 IP 192.168.99.30.58951 > google-public-dns-a.google.com.domain: 43247+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:12:57.781113 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1d), length 132
22:12:57.781205 IP 192.168.99.30.54783 > google-public-dns-a.google.com.domain: 23664+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:12:57.783334 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1e), length 116
22:12:57.783517 IP 192.168.99.30.59004 > google-public-dns-a.google.com.domain: 52441+ A? www.apple.com. (31)
22:12:57.785164 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x1f), length 132
22:12:57.785263 IP 192.168.99.30.64045 > google-public-dns-a.google.com.domain: 45714+ A? 1-courier.push.apple.com. (42)
22:12:57.786786 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x20), length 132
22:12:57.786894 IP 192.168.99.30.62067 > google-public-dns-a.google.com.domain: 46874+ A? init-p01st.push.apple.com. (43)
22:12:57.789180 IP 77-172-73-184.ip.telfort.nl.sae-urn > vps4.sparklingclouds.nl.sae-urn: UDP-encap: ESP(spi=0x07a381bb,seq=0x21), length 132

Here is output from "tcpdump -i xn0 'net 192.168.99.0/24'" while executing 'ping 8.8.8.8' on the connected host:

Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xn0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:22:15.782866 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:15.785902 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:15.787667 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:15.790870 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:15.793110 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:15.795761 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:15.798005 IP 192.168.99.30.58864 > google-public-dns-a.google.com.domain: 21331+ A? www.isg-apple.com.akadns.net. (46)
22:22:15.800780 IP 192.168.99.30.55845 > google-public-dns-a.google.com.domain: 4395+ A? 1.courier-push-apple.com.akadns.net. (53)
22:22:15.802892 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:15.804885 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:15.808933 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:15.811028 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:15.812989 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:15.814934 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:15.816811 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:15.819718 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:15.906065 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796636288 ecr 0,sackOK,eol], length 0
22:22:16.828830 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:16.832879 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:16.834918 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:16.838007 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:16.839870 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:16.841825 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:16.844653 IP 192.168.99.30.58864 > google-public-dns-a.google.com.domain: 21331+ A? www.isg-apple.com.akadns.net. (46)
22:22:16.846636 IP 192.168.99.30.55845 > google-public-dns-a.google.com.domain: 4395+ A? 1.courier-push-apple.com.akadns.net. (53)
22:22:16.849899 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:16.851952 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:16.855361 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:16.857961 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:16.859905 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:16.861748 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:16.863718 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:16.867099 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:16.962796 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796637356 ecr 0,sackOK,eol], length 0
22:22:18.115888 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796638455 ecr 0,sackOK,eol], length 0
22:22:19.081221 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796639456 ecr 0,sackOK,eol], length 0
22:22:19.850811 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:19.853767 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:19.855674 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:19.858982 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:19.861100 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:19.863964 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:19.866785 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:19.869003 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:19.871610 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:19.873961 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:19.876006 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:19.877943 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:19.880054 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:19.882805 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:20.191033 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796640556 ecr 0,sackOK,eol], length 0
22:22:20.922147 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:20.926671 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:20.927966 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:20.930959 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:20.933203 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:20.944000 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:20.947169 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:20.949144 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:20.951925 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:20.954062 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:20.955706 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:20.957992 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:20.961030 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:20.963111 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:21.207137 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796641560 ecr 0,sackOK,eol], length 0
22:22:23.346217 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796643657 ecr 0,sackOK,eol], length 0
22:22:23.969908 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:23.971976 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:23.975115 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:23.977304 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:23.979928 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:23.982832 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:23.984968 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:23.988223 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:23.990057 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:23.993296 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:23.995142 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:23.997019 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:23.999023 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:24.001023 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:27.352672 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,sackOK,eol], length 0
22:22:30.962806 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 0, length 64
22:22:31.990199 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 1, length 64
22:22:32.968429 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 2, length 64
22:22:33.041233 IP 192.168.99.30.62883 > google-public-dns-a.google.com.domain: 23404+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:33.044331 IP 192.168.99.30.64018 > google-public-dns-a.google.com.domain: 56204+ PTR? b._dns-sd._udp.0.0.0.10.in-addr.arpa. (54)
22:22:33.046125 IP 192.168.99.30.60733 > google-public-dns-a.google.com.domain: 64993+ PTR? db._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
22:22:33.049438 IP 192.168.99.30.65454 > google-public-dns-a.google.com.domain: 38737+ A? sublimetext.com. (33)
22:22:33.052352 IP 192.168.99.30.53892 > google-public-dns-a.google.com.domain: 60585+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
22:22:33.054252 IP 192.168.99.30.55341 > google-public-dns-a.google.com.domain: 38580+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:33.057138 IP 192.168.99.30.59899 > google-public-dns-a.google.com.domain: 23799+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
22:22:33.059255 IP 192.168.99.30.53018 > google-public-dns-a.google.com.domain: 60200+ PTR? 30.99.168.192.in-addr.arpa. (44)
22:22:33.062106 IP 192.168.99.30.52922 > google-public-dns-a.google.com.domain: 30510+ A? 1-courier.sandbox.push.apple.com. (50)
22:22:33.064235 IP 192.168.99.30.59548 > google-public-dns-a.google.com.domain: 43902+ A? www.apple.com. (31)
22:22:33.066423 IP 192.168.99.30.52933 > google-public-dns-a.google.com.domain: 13895+ A? 1-courier.push.apple.com. (42)
22:22:33.069371 IP 192.168.99.30.61283 > google-public-dns-a.google.com.domain: 59159+ A? ponify.nl. (27)
22:22:33.071312 IP 192.168.99.30.65124 > google-public-dns-a.google.com.domain: 32342+ A? radarsubmissions.apple.com. (44)
22:22:33.073136 IP 192.168.99.30.55959 > google-public-dns-a.google.com.domain: 22645+ A? 16-courier.push.apple.com. (43)
22:22:33.998205 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 3, length 64
22:22:34.966138 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 4, length 64
22:22:35.448668 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,sackOK,eol], length 0
22:22:35.975377 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 5, length 64
22:22:36.967603 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 6, length 64
22:22:37.985342 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 7, length 64
22:22:39.010421 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 8, length 64
22:22:39.973774 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 9, length 64
22:22:40.997722 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 10, length 64
22:22:41.975523 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 11, length 64
22:22:43.000790 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 12, length 64
22:22:43.993444 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 13, length 64
22:22:45.024641 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 14, length 64
22:22:45.437720 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796665670 ecr 0,sackOK,eol], length 0
22:22:45.440413 IP 192.168.99.30.65088 > google-public-dns-a.google.com.domain: 50367+ A? api.ip2info.org. (33)
22:22:45.712881 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796665919 ecr 0,sackOK,eol], length 0
22:22:45.769194 IP 192.168.99.30.53062 > google-public-dns-a.google.com.domain: 5438+ A? 9-courier.push.apple.com. (42)
22:22:45.987644 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 15, length 64
22:22:46.469821 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796666713 ecr 0,sackOK,eol], length 0
22:22:46.515832 IP 192.168.99.30.65088 > google-public-dns-a.google.com.domain: 50367+ A? api.ip2info.org. (33)
22:22:46.866680 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796667014 ecr 0,sackOK,eol], length 0
22:22:46.868577 IP 192.168.99.30.53062 > google-public-dns-a.google.com.domain: 5438+ A? 9-courier.push.apple.com. (42)
22:22:46.975732 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 16, length 64
22:22:47.514391 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796667715 ecr 0,sackOK,eol], length 0
22:22:47.837539 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796668016 ecr 0,sackOK,eol], length 0
22:22:47.979870 IP 192.168.99.30 > google-public-dns-a.google.com: ICMP echo request, id 19972, seq 17, length 64
22:22:48.514631 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796668719 ecr 0,sackOK,eol], length 0
22:22:48.787566 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796669021 ecr 0,sackOK,eol], length 0
22:22:49.497980 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796669723 ecr 0,sackOK,eol], length 0
22:22:49.578808 IP 192.168.99.30.65088 > google-public-dns-a.google.com.domain: 50367+ A? api.ip2info.org. (33)
22:22:49.870896 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796670025 ecr 0,sackOK,eol], length 0
22:22:49.901842 IP 192.168.99.30.53062 > google-public-dns-a.google.com.domain: 5438+ A? 9-courier.push.apple.com. (42)
22:22:50.502806 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796670728 ecr 0,sackOK,eol], length 0
22:22:50.582187 IP 192.168.99.30.65088 > google-public-dns-a.google.com.domain: 50367+ A? api.ip2info.org. (33)
22:22:50.803820 IP 192.168.99.30.49767 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 4118214570, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796671031 ecr 0,sackOK,eol], length 0
22:22:50.968985 IP 192.168.99.30.53062 > google-public-dns-a.google.com.domain: 5438+ A? 9-courier.push.apple.com. (42)
22:22:51.526759 IP 192.168.99.30.49765 > ee-in-f99.1e100.net.https: Flags [S], seq 2824157881, win 65535, options [mss 1240,sackOK,eol], length 0
22:22:52.517902 IP 192.168.99.30.49766 > static.132.61.63.178.clients.your-server.de.https: Flags [S], seq 1926932048, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 796672736 ecr 0,sackOK,eol], length 0
^C
137 packets captured
678 packets received by filter
0 packets dropped by kernel
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

Hmm... You should not be seeing 192.168.99.0/24 on xn0. It should already be NAT'd at that point.

What does pfctl -vsa | head 4 output? Your NAT rule should be the first rule. It should have some hits on it's counters.

Also, some rule changes to test it out:
($ext_if:0) ensures it dynamically uses the first address on $ext_if and avoids aliases or anything else
Code:
nat on $ext_if inet from $vpn_net to any -> ($ext_if:0)
If pings still aren't working, try having it NAT everything not from $ext_if. Maybe packets originating directly from the VPN are seen as just outbound connections rather than forwarded packets. Might be worth a shot to see what happens.
Code:
nat on $ext_if inet from !($ext_if) to any -> ($ext_if:0)
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

Here is the pfctl output:

Code:
[root@vps4 ~]# pfctl -vsa | head -n 10
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on xn0 inet from 192.168.99.0/24 to any -> 64.188.45.131
  [ Evaluations: 32571     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 923 State Creations: 0     ]

FILTER RULES:
pass in on xn0 inet proto udp from any to (self) port = l2f keep state
  [ Evaluations: 627582    Packets: 24        Bytes: 1680        States: 0     ]
  [ Inserted: uid 0 pid 923 State Creations: 3     ]

After changing the nat rule to:

Code:
nat on $ext_if inet from $vpn_net to any -> ($ext_if:0)

And restarting pf it also does not work:

Code:
[root@vps4 ~]# pfctl -vsa | head -n 10
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on xn0 inet from 192.168.99.0/24 to any -> (xn0:0)
  [ Evaluations: 54        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 43069 State Creations: 0     ]

FILTER RULES:
pass in on xn0 inet proto udp from any to (self) port = l2f keep state
  [ Evaluations: 338       Packets: 2         Bytes: 140         States: 1     ]
  [ Inserted: uid 0 pid 43069 State Creations: 1     ]
pass in on xn0 inet proto udp from any to (self) port = isakmp keep state

Next, the following change:

Code:
nat on $ext_if inet from !($ext_if) to any -> ($ext_if:0)

same result after restarting pf, it does not work:

Code:
[root@vps4 ~]# pfctl -vsa | head -n 10
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on xn0 inet from ! (xn0) to any -> (xn0:0)
  [ Evaluations: 60        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 43267 State Creations: 0     ]

FILTER RULES:
pass in on xn0 inet proto udp from any to (self) port = l2f keep state
  [ Evaluations: 376       Packets: 2         Bytes: 140         States: 1     ]
  [ Inserted: uid 0 pid 43267 State Creations: 1     ]
pass in on xn0 inet proto udp from any to (self) port = isakmp keep state

In both cases tcpdump shows traffic on xn0:

Code:
[root@vps4 ~]# tcpdump -i xn0 "net 192.168.99.0/24"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xn0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:49:43.312159 IP 192.168.99.30.61073 > 192.168.241.26.domain: 50426+ A? www.google.com. (32)
01:49:43.319898 IP 192.168.99.30.51043 > google-public-dns-a.google.com.domain: 49243+ PTR? b._dns-sd._udp.0.3.20.172.in-addr.arpa. (56)
01:49:43.320564 IP 192.168.99.30.62027 > google-public-dns-a.google.com.domain: 10019+ PTR? db._dns-sd._udp.0.3.20.172.in-addr.arpa. (57)
01:49:43.320631 IP 192.168.99.30.63306 > google-public-dns-a.google.com.domain: 22063+ PTR? lb._dns-sd._udp.0.3.20.172.in-addr.arpa. (57)
01:49:43.320649 IP 192.168.99.30.59781 > google-public-dns-a.google.com.domain: 6110+ A? sublimetext.com. (33)
01:49:43.320665 IP 192.168.99.30.59272 > google-public-dns-a.google.com.domain: 1148+ PTR? b._dns-sd._udp.0.5.20.172.in-addr.arpa. (56)
01:49:43.320675 IP 192.168.99.30.59878 > google-public-dns-a.google.com.domain: 45051+ PTR? db._dns-sd._udp.0.5.20.172.in-addr.arpa. (57)
01:49:43.324529 IP 192.168.99.30.49294 > google-public-dns-a.google.com.domain: 34798+ PTR? lb._dns-sd._udp.0.5.20.172.in-addr.arpa. (57)
01:49:43.324551 IP 192.168.99.30.63015 > google-public-dns-a.google.com.domain: 36975+ A? ponify.nl. (27)
01:49:43.324561 IP 192.168.99.30.52340 > google-public-dns-a.google.com.domain: 30349+ A? 1.courier-sandbox-push-apple.com.akadns.net. (61)
01:49:43.324570 IP 192.168.99.30.62636 > google-public-dns-a.google.com.domain: 56918+ A? e3191.dscc.akamaiedge.net. (43)
01:49:43.324579 IP 192.168.99.30.51815 > google-public-dns-a.google.com.domain: 13290+ A? us-courier.push-apple.com.akadns.net. (54)
01:49:43.324591 IP 192.168.99.30.61844 > google-public-dns-a.google.com.domain: 3612+ PTR? b._dns-sd._udp.0.99.168.192.in-addr.arpa. (58)
01:49:43.324599 IP 192.168.99.30.56671 > google-public-dns-a.google.com.domain: 36904+ PTR? db._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
01:49:43.324608 IP 192.168.99.30.58013 > google-public-dns-a.google.com.domain: 4467+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
01:49:43.331929 IP 192.168.99.30.58922 > google-public-dns-a.google.com.domain: 50080+ PTR? 30.99.168.192.in-addr.arpa. (44)
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

Well, we're getting somewhere. Here is an example of what you should be seeing. I did a service pf reload and immediately starting pinging 8.8.8.8 from within my LAN.
Code:
# tcpdump -n -i em2 host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
21:38:10.051428 IP xx.xx.156.202 > 8.8.8.8: ICMP echo request, id 5251, seq 1, length 64
21:38:10.082835 IP 8.8.8.8 > xx.xx.156.202: ICMP echo reply, id 5251, seq 1, length 64
21:38:11.053913 IP xx.xx.156.202 > 8.8.8.8: ICMP echo request, id 5251, seq 2, length 64
21:38:11.084851 IP 8.8.8.8 > xx.xx.156.202: ICMP echo reply, id 5251, seq 2, length 64
21:38:12.055255 IP xx.xx.156.202 > 8.8.8.8: ICMP echo request, id 5251, seq 3, length 64
21:38:12.086059 IP 8.8.8.8 > xx.xx.156.202: ICMP echo reply, id 5251, seq 3, length 64
Code:
# pfctl -vsa | head -4
TRANSLATION RULES:
nat on em2 inet from ! (em2) to any -> (em2:0)
  [ Evaluations: 4         Packets: 6         Bytes: 504         States: 1     ]
  [ Inserted: uid 0 pid 67695 State Creations: 1     ]

As you can see, the pings work and the packets and state counter on that NAT rule is incrementing. In all your output, the rule is evaluated passed but isn't matching. So we can see the symptom here but don't see the cause. Nothing is getting NAT'd for some reason. My thought is to start ruling stuff out. I have no idea what happens when both ipfw and PF are running. Are both used? If one is used and a rule is matched, does it avoid the other? Did the networking and firewall behavior between 9 and 10 change that affects this? Maybe this guide worked on 9 at one point. Point is, there's a lot of questions to answer and I'm thinking if we simplify this the cause will be clearer.

My recommendation would be to remove all the firewall_* lines from /etc/rc.conf, remove net.pfil.forward=1 from /etc/sysctl.conf since it doesn't even exist in 10, and remove all the ipfw parts from the kernel. Let's try the same test again with just PF after doing that.
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

I like that we are getting somewhere :) . As said, the IPFW was because the 9 tutorial suggested that. I've done the following steps as you suggested:

Recompiled a new kernel with only the following (other than GENERIC) options:

Code:
# VPN
options         IPSEC
options         IPSEC_NAT_T
device          crypto
device          enc

# Firewall & NAT for VPN
options         IPSEC_FILTERTUNNEL
options         LIBALIAS

(and booted it of course)

Removed the lines from /etc/rc.conf:

Code:
cat /etc/rc.conf
hostname="vps4.sparklingclouds.nl"
ifconfig_re0="DHCP"
ifconfig_xn0="DHCP"
ifconfig_xn0_ipv6="inet6 accept_rtadv"
ifconfig_re0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
ntpd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
nginx_enable="YES"
linux_enable="YES"
ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf"
racoon_enable="YES"
racoon_flags="-l /var/log/racoon.log"
mpd_enable="YES"
pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
gateway_enable="YES"

Yet again, with all three PF rules suggested above, no results yet:

Code:
[root@vps4 ~]# pfctl -vsa | head -n 10
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on xn0 inet from 192.168.99.0/24 to any -> (xn0:0)
  [ Evaluations: 63        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 1659 State Creations: 0     ]

FILTER RULES:
pass in on xn0 inet proto udp from any to (self) port = l2f keep state
  [ Evaluations: 270       Packets: 8         Bytes: 560         States: 1     ]
  [ Inserted: uid 0 pid 1659 State Creations: 1     ]
pass in on xn0 inet proto udp from any to (self) port = isakmp keep state


except for the same traffic on xn0:

Code:
[root@vps4 ~]# tcpdump -i xn0 "net 192.168.99.0/24"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xn0, link-type EN10MB (Ethernet), capture size 65535 bytes
02:06:36.824285 IP 192.168.99.30.55899 > google-public-dns-a.google.com.domain: 48144+ A? sublimetext.com. (33)
02:06:36.824479 IP 192.168.99.30.53578 > google-public-dns-a.google.com.domain: 26793+ PTR? lb._dns-sd._udp.0.4.20.172.in-addr.arpa. (57)
02:06:36.825257 IP 192.168.99.30.58246 > google-public-dns-a.google.com.domain: 56664+ PTR? lb._dns-sd._udp.0.254.168.192.in-addr.arpa. (60)
02:06:36.825488 IP 192.168.99.30.56828 > google-public-dns-a.google.com.domain: 32806+ A? 1.courier-sandbox-push-apple.com.akadns.net. (61)
02:06:36.825506 IP 192.168.99.30.50697 > google-public-dns-a.google.com.domain: 33002+ A? www.isg-apple.com.akadns.net. (46)
02:06:36.825517 IP 192.168.99.30.54528 > google-public-dns-a.google.com.domain: 40218+ A? us-courier.push-apple.com.akadns.net. (54)
02:06:36.825529 IP 192.168.99.30.49682 > google-public-dns-a.google.com.domain: 22753+ A? ponify.nl. (27)
02:06:36.825838 IP 192.168.99.30.62692 > google-public-dns-a.google.com.domain: 56581+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
02:06:36.825997 IP 192.168.99.30.59402 > google-public-dns-a.google.com.domain: 61658+ PTR? 30.99.168.192.in-addr.arpa. (44)
02:06:36.826029 IP 192.168.99.30.55259 > google-public-dns-a.google.com.domain: 35368+ A? 1-courier.sandbox.push.apple.com. (50)
02:06:36.826157 IP 192.168.99.30.62851 > google-public-dns-a.google.com.domain: 50004+ A? 1-courier.push.apple.com. (42)
02:06:36.826259 IP 192.168.99.30.59077 > google-public-dns-a.google.com.domain: 1219+ A? www.apple.com. (31)
02:06:36.826963 IP 192.168.99.30.51274 > google-public-dns-a.google.com.domain: 62685+ A? 50-courier.push.apple.com. (43)
02:06:36.828134 IP 192.168.99.30.28167 > 10.176.0.8.domain: 1518+ A? www.google.com. (32)
02:06:37.900770 IP 192.168.99.30.49493 > google-public-dns-a.google.com.domain: 4488+ PTR? lb._dns-sd._udp.0.0.169.10.in-addr.arpa. (57)
02:06:37.901451 IP 192.168.99.30.55899 > google-public-dns-a.google.com.domain: 48144+ A? sublimetext.com. (33)
02:06:37.901673 IP 192.168.99.30.53578 > google-public-dns-a.google.com.domain: 26793+ PTR? lb._dns-sd._udp.0.4.20.172.in-addr.arpa. (57)
02:06:37.901688 IP 192.168.99.30.58246 > google-public-dns-a.google.com.domain: 56664+ PTR? lb._dns-sd._udp.0.254.168.192.in-addr.arpa. (60)
02:06:37.901831 IP 192.168.99.30.56828 > google-public-dns-a.google.com.domain: 32806+ A? 1.courier-sandbox-push-apple.com.akadns.net. (61)
02:06:37.902005 IP 192.168.99.30.50697 > google-public-dns-a.google.com.domain: 33002+ A? www.isg-apple.com.akadns.net. (46)
02:06:37.902220 IP 192.168.99.30.54528 > google-public-dns-a.google.com.domain: 40218+ A? us-courier.push-apple.com.akadns.net. (54)
02:06:37.902240 IP 192.168.99.30.49682 > google-public-dns-a.google.com.domain: 22753+ A? ponify.nl. (27)
02:06:37.902400 IP 192.168.99.30.62692 > google-public-dns-a.google.com.domain: 56581+ PTR? lb._dns-sd._udp.0.99.168.192.in-addr.arpa. (59)
02:06:37.902631 IP 192.168.99.30.59402 > google-public-dns-a.google.com.domain: 61658+ PTR? 30.99.168.192.in-addr.arpa. (44)
02:06:37.902650 IP 192.168.99.30.55259 > google-public-dns-a.google.com.domain: 35368+ A? 1-courier.sandbox.push.apple.com. (50)
02:06:37.902927 IP 192.168.99.30.62851 > google-public-dns-a.google.com.domain: 50004+ A? 1-courier.push.apple.com. (42)
02:06:37.903024 IP 192.168.99.30.59077 > google-public-dns-a.google.com.domain: 1219+ A? www.apple.com. (31)
02:06:37.903039 IP 192.168.99.30.51274 > google-public-dns-a.google.com.domain: 62685+ A? 50-courier.push.apple.com. (43)
02:06:38.916366 IP 192.168.99.30.58879 > google-public-dns-a.google.com.domain: 62469+ A? hoyplkxrpl.digidentity.eu. (43)
02:06:38.919523 IP 192.168.99.30.59410 > google-public-dns-a.google.com.domain: 21424+ A? yhdhyxsgcg.digidentity.eu. (43)
02:06:38.919543 IP 192.168.99.30.9231 > google-public-dns-a.google.com.domain: 52896+ A? ibijdlodin.digidentity.eu. (43)
02:06:39.925072 IP 192.168.99.30.56023 > google-public-dns-a.google.com.domain: 25344+ A? hoyplkxrpl.digidentity.eu. (43)
02:06:39.926594 IP 192.168.99.30.3414 > google-public-dns-a.google.com.domain: 51209+ A? yhdhyxsgcg.digidentity.eu. (43)
02:06:39.926751 IP 192.168.99.30.50375 > google-public-dns-a.google.com.domain: 3968+ A? ibijdlodin.digidentity.eu. (43)
02:06:40.652959 IP 192.168.99.30.61587 > static.5.49.63.178.clients.your-server.de.https: Flags [S], seq 1236550311, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 837924023 ecr 0,sackOK,eol], length 0
02:06:40.653023 IP 192.168.99.30.56083 > google-public-dns-a.google.com.domain: 12275+ A? api.ip2info.org. (33)
02:06:40.905139 IP 192.168.99.30.61588 > static.5.49.63.178.clients.your-server.de.https: Flags [S], seq 3498706074, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 837924263 ecr 0,sackOK,eol], length 0
02:06:40.954637 IP 192.168.99.30.61589 > srv044083.webreus.nl.http: Flags [S], seq 653325606, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS val 837924310 ecr 0,sackOK,eol], length 0
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

It looks like there was some issues with IPSEC and firewalling on 10.0-RELEASE. Something about an mbuf flag to skip firewalling. I'm going to have to read these links a bit closer when I get some more time. The first Google search for "FreeBSD 10 IPSEC NAT" returned the following page describing the exact symptoms we see:

http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076900.html

A little bit more digging and I came across this PR with a very confusing description in the PR itself but linked to a forum post where they described the same symptom with ipfw.
http://www.freebsd.org/cgi/query-pr.cgi?pr=185876
http://forums.freebsd.org/viewtopic.php?f=39&t=26755&start=100#p248323

The PR is closed so it looks like you'll either have to use STABLE to get it to work or locally apply the patches yourself to the 10.0-RELEASE source you already have.
 
Re: IPSEC/L2TP VPN on 10.0, no traffic to internet

junovitch said:
It looks like there was some issues with IPSEC and firewalling on 10.0-RELEASE. Something about an mbuf flag to skip firewalling. I'm going to have to read these links a bit closer when I get some more time. The first Google search for "FreeBSD 10 IPSEC NAT" returned the following page describing the exact symptoms we see:

http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076900.html

A little bit more digging and I came across this PR with a very confusing description in the PR itself but linked to a forum post where they described the same symptom with ipfw.
http://www.freebsd.org/cgi/query-pr.cgi?pr=185876
http://forums.freebsd.org/viewtopic.php?f=39&t=26755&start=100#p248323

The PR is closed so it looks like you'll either have to use STABLE to get it to work or locally apply the patches yourself to the 10.0-RELEASE source you already have.

After an upgrade to 10.0-STABLE it now works as excpected. So it was indeed that bug. Thank you very much for helping me. Any idea when this will be going in to RELEASE?
 
Back
Top