Hi,
I have set up my NetBSD/amd64 7.0_STABLE notebook (including lastest
netipsec patches) with a Huawei E3131 UMTS surfstick to allow internet
connections via ppp0.
For my problem it makes no difference whether internet access is via WWAN or
LAN, but WWAN is the configuration it is intended to work with in the end.
Without VPN, routing is fine and I can access all internet sites. The normal
routing table:
Destination Gateway Flags Refs Use Mtu
Interface
default 10.64.64.64 UGS - - -L ppp0
10.64.64.64 100.85.193.130 UH - - -L ppp0
127/8 127.0.0.1 UGRS - - 33648L lo0
127.0.0.1 127.0.0.1 UH - - 33648L lo0
192.168.45/24 link#1 UC - - -L re0
# ifconfig ppp0
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 100.85.193.130 -> 10.64.64.64 netmask 0xff000000
inet6 fe80::2e56:dcff:fe04:a5ff%ppp0 -> prefixlen 64 scopeid 0x3
Now I establish the IPsec VPN connection with my gateway at 1.2.3.4 (not the
real address). I'm using more or less the default Phase1-Up script, which
does this:
if=`netstat -finet -rn|awk '($1 == "default"){print $7; exit}'`
ifconfig ${if} alias ${INTERNAL_ADDR4} netmask ${INTERNAL_NETMASK4}
route delete default
route add default ${DEFAULT_GW} -ifa ${INTERNAL_ADDR4}
route add ${REMOTE_ADDR} ${DEFAULT_GW}
The VPN is up and running and I can work with all sites in my VPN LAN
(192.168.0.0/24):
Mar 16 14:39:18 enceladus racoon: INFO: IPsec-SA established: ESP/Tunnel
100.85.193.130[4500]->1.2.3.4[4500] spi=11295294(0xac5a3e)
Mar 16 14:39:18 enceladus racoon: INFO: IPsec-SA established: ESP/Tunnel
100.85.193.130[4500]->1.2.3.4[4500] spi=259744464(0xf7b62d0)
My SPD entries:
192.168.0.0/24[any] 192.168.0.213[any] reserved
in ipsec
esp/tunnel/1.2.3.4-100.85.193.130/require
spid=12 seq=1 pid=1385
refcnt=1
192.168.0.213[any] 192.168.0.0/24[any] reserved
out ipsec
esp/tunnel/100.85.193.130-1.2.3.4/require
spid=11 seq=0 pid=1385
refcnt=1
My routing table looks the same. Just one entry for the VPN gateway was
added:
Destination Gateway Flags Refs Use Mtu
Interface
default 10.64.64.64 UGS - - -L ppp0
10.64.64.64 100.85.193.130 UH - - -L ppp0
127/8 127.0.0.1 UGRS - - 33648L lo0
127.0.0.1 127.0.0.1 UH - - 33648L lo0
192.168.45/24 link#1 UC - - -L re0
1.2.3.4 10.64.64.64 UGHS - - -L ppp0
And the ppp0 interface got an alias. I tried it without the alias, but then
VPN doesn't work at all:
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 100.85.193.130 -> 10.64.64.64 netmask 0xff000000
inet alias 192.168.0.213 -> netmask 0xffffff00
inet6 fe80::2e56:dcff:fe04:a5ff%ppp0 -> prefixlen 64 scopeid 0x3
Internet access within the VPN LAN 192.168.0 usually works through the
gateway 192.168.0.1. But also my own PPP gateway 100.85.193.130 should be
able to route packets into the internet. But it stops working, when
connected with VPN:
# ping 8.8.8.8
PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes
The nameserver from the VPN (192.168.0.251) works, but there is no reply.
# tcpdump -n -i ppp0
14:55:49.410338 IP: IP 192.168.0.213 > 8.8.8.8: ICMP echo request, id 34226,
seq 0, length 64
14:55:50.414873 IP: IP 192.168.0.213 > 8.8.8.8: ICMP echo request, id 34226,
seq 1, length 64
14:55:51.425377 IP: IP 192.168.0.213 > 8.8.8.8: ICMP echo request, id 34226,
seq 2, length 64
Ok, the packet is not encrypted, which is ok, as the destination is not the
VPN LAN. But it uses my VPN alias address 192.168.0.213 for the sender.
Maybe this is the problem?
But what can I do to make it work? I tried to change my policies to route
everything encrypted over the VPN gateway, like this:
0.0.0.0/0[any] 192.168.0.213[any] reserved
in ipsec
esp/tunnel/1.2.3.4-100.85.193.130/require
spid=12 seq=1 pid=1385
refcnt=1
192.168.0.213[any] 0.0.0.0./0[any] reserved
out ipsec
esp/tunnel/100.85.193.130-1.2.3.4/require
spid=11 seq=0 pid=1385
refcnt=1
But then it still doesn't want to route my WAN packets:
# ping 8.8.8.8
PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes
36 bytes from 192.168.0.1: Destination Host Unreachable for icmp_seq=0
36 bytes from 192.168.0.1: Destination Host Unreachable for icmp_seq=1
[...]
It works when logging in into a real 192.168.0.0/24 LAN host.
--
Frank Wille
