Date: Thu, 28 Oct 2004 10:38:19 -0700 From: Aaron Nichols <adnichols@gmail.com> To: freebsd-net@freebsd.org Subject: Problems with NAT on gif interface for VPN Message-ID: <ac0553840410281038224213b@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
All,
I didn't get any hits on freebsd-questions so I'm re-posting this
here. Any help is much appreciated. This is 4.10-RELEASE-p2.
--
All,
I'm having a problem getting nat to work on a gif interface. My
goal here is to have a FreeBSD host (which is the gateway for a home
network) connect to a VPN using a "client vpn" setup and masquerade
(nat) the network behind the FreeBSD host using a single IP provided
by the corporate VPN server.
At this point I have racoon/ipfw/natd working to the point that I
can pass traffic over the VPN from the FreeBSD host itself just fine.
However, if I send traffic from a client on the LAN, it goes all the
way across the VPN, I see the destination host send a response and I
see the incoming ESP packet on the FreeBSD hosts wan interface, but I
never see the packet sent out the LAN and I'm having trouble tracking
where it is being dropped. If I perform a packet capture on gif0, I
see neither the outgoing or incoming traffic, which seems incorrect to
me since I do know the traffic is going out and is coming back when I
initiate it from the FreeBSD host itself.
I have started two natd processes bound to two different ports for
divert use on each interface, they are shown below.
Anyways, here are the details:
Host A (FreeBSD)
LAN: 192.168.1.1/24
WAN: a.b.c.d (dynamic IP from cable provider)
Host B (VPN server)
LAN: 10.1.8.12/24 (larger /8 behind this)
WAN: w.x.y.z
VPN client IP is 10.1.13.100
---
setkey -DP:
w.x.y.z[any] a.b.c.d[any] ip4
in ipsec
esp/tunnel/w.x.y.z-a.b.c.d/require
spid=67 seq=3 pid=94282
refcnt=1
10.0.0.0/8[any] 10.1.13.100[any] any
in ipsec
esp/tunnel/w.x.y.z-a.b.c.d/require
spid=69 seq=2 pid=94282
refcnt=1
a.b.c.d[any] w.x.y.z[any] ip4
out ipsec
esp/tunnel/a.b.c.d-w.x.y.z/require
spid=66 seq=1 pid=94282
refcnt=1
10.1.13.100[any] 10.0.0.0/8[any] any
out ipsec
esp/tunnel/a.b.c.d-w.x.y.z/require
spid=68 seq=0 pid=94282
refcnt=1
---
Relevant routing entries
Destination Gateway Flags Refs Use Netif Expire
10 10.1.8.12 UGSc 1 9098 gif0
10.1.8.12 10.1.13.100 UH 1 0 gif0
---
ifconfig:
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::260:8ff:fea5:d095%xl0 prefixlen 64 scopeid 0x1
inet a.b.c.d netmask 0xfffffe00 broadcast 255.255.255.255
ether 00:60:08:a5:d0:95
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::250:8dff:fe5d:c6d%vr0 prefixlen 64 scopeid 0x2
inet 192.168.1.2 netmask 0xffffffff broadcast 192.168.1.2
ether 00:50:8d:5d:0c:6d
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
gif0: flags=28151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> mtu 1280
tunnel inet a.b.c.d --> w.x.y.z
inet6 fe80::260:8ff:fea5:d095%gif0 prefixlen 64 scopeid 0x8
inet 10.1.13.100 --> 10.1.8.12 netmask 0xffffffff
---
natd processes (latter is setup for debugging):
/sbin/natd -dynamic -use_sockets -unregistered_only -n xl0
/sbin/natd -v -l -n gif0 -log_denied -p 8669
---
ipfw show
(Yes, this set isn't that clean - it's been hacked up while trying to
figure out this issue - please forgive any redundancies or
ineficiencies you see unless they may impact this problem)
00100 1458262 852524563 divert 8668 ip from any to any via xl0
00200 3436 370488 divert 8669 ip from any to any via gif0
00300 0 0 check-state
00400 890895 403006370 allow ip from any to any keep-state out xmit xl0
00500 0 0 allow ip from any to any keep-state via gif0
00600 4 432 allow esp from any to any
00700 0 0 allow udp from any to me 500 in
00800 2770 5371008 allow ip from any to any via lo0
00900 1364895 918328465 allow ip from any to any keep-state via vr0
01000 6699 1015786 allow tcp from any to any 22 keep-state in
01100 44273 13145900 allow tcp from any to any 25 keep-state in
01200 3361 1924613 allow tcp from any to any 80 keep-state in
01300 392 26364 allow icmp from any to any
01400 55996 18161747 deny log ip from any to any
65535 104 11992 deny ip from any to any
--
So, at this point when I send traffic from a machine on the LAN, I can
confirm the following:
NAT seems to work based on the debug output of natd:
Out [ICMP] [ICMP] 192.168.1.101 -> 10.1.2.115 8(0) aliased to
[ICMP] 10.1.13.100 -> 10.1.2.115 8(0)
I see the icmp packet reach the other side of the VPN via tcpdump, and
I see an icmp echo response sent back. If I sniff my xl0 interface
while doing this I see the following:
11:03:34.093263 a.b.c.d > w.x.y.z: ESP(spi=0xa9c55011,seq=0x5)
11:03:34.128605 w.x.y.z > a.b.c.d.167: ESP(spi=0x0dcf2aab,seq=0x5)
These packets correspond w/ the ICMP request/response I see on the
other side of the VPN so I assume that 2nd ESP packet is the ping
response.
My problem is that I never see any icmp on gif0 (neither the ping
request or response) and I never see the icmp response on vr0.
Obviously the machine on the LAN never recieves it either.
Questions:
1) Why would I not be seeing all traffic over the VPN on gif0? It
doesn't seem likely that it's going via another interface because the
source of traffic is correct and NAT seems to be working outbound, so
I think I should see it.
2) Are there problems with my configuration which anyone can identify
as preventing only the response traffic back into this network?
If you need additional info I'm happy to provide it - but I thought
this was a good (and definitely long enough) starting point. If there
is another list better suited to answering this questions let me know.
Thanks in advance,
Aaron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac0553840410281038224213b>