In article <47dd3b543a0.3f873...@mail.owl.de>,
Frank Wille <fr...@phoenix.owl.de> wrote:
>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.
I knew someone would eventually discover this... Yes, things don't
work very well on the machine that has the IPSEC endpoint. I meant
to debug this too but it was not very important to me to spend the
time so far :-) Using ping -I to select the source address should
work, but it seems that it does not (last time I tried it).
christos
