On 01.09-21:00, Stijn wrote:
> n0g0013 wrote:
> >not sure where to start debugging this VPN problem. i have an ipsec,
> >nat-t tunnel between a development network and the main services hub
> >using isakmpd. the exchange seems to go smoothly and the tunnel gets
> >established.
> >
> > hub(public_ip) --> {inet} <-- ext-gw(nat-ip) <-- dev-gw(private_ip)
> >
> >however no traffic gets through from the hub. this is a sample dump
> >of a ping from the VPN hub to the development gateway.
> >
> > 12:02:24.890060 (authentic,confidential): SPI 0x088b62c7:
> > 10.12.228.17 > 10.12.170.9: icmp: echo request
> > (encap)
> > 12:02:24.891659 193.200.155.117.4500 >
> > 193.200.155.18.46289:udpencap: esp 193.200.155.117 >
> > 193.200.155.18
> > spi 0x088B62C7 seq 2 len 116
> > 12:02:24.892778 193.200.155.18.46289 >
> > 193.200.155.117.4500:udpencap: esp 193.200.155.18 >
> > 193.200.155.117
> > spi 0xE99A3368 seq 27 len 116
> >
> >as you can see, the echo request passes out the 'enc0' and down the
> >tunnel to the remote end, where it is apparently decoded and a ping
> >response is sent back. this response hits the external interface
> >and disappears.
> >
> >i have no clue where to start tracking this down from here. can i
> >somehow track this lost packet beyond the external inferace? or
> >must i manually decode the packet at this stage and try to uncover
> >the issue from there? also, if the packet was malformed or
> >erroneous could i expect an error log of some description?
> >
> >any pointers would be appreciated.
> >
> >nb: disabling 'pf' has no effect
> >
> does the reply packets know the way back? i.e. is there a route defined
> to route the traffic back into the tunnel? Do you see esp traffic
> returning to the development gw?
the dumps are on the hub using both 'enc0' and the external interface.
you can see the echo request go out on 'enc0' (the first line) and
the udpencap pass out the external interface toward the dev-gw. the
final packet above is the returning echo-reply from the dev-gw. it
does not not re-appear anywhere at the hub. you may note that the
ping is sent from the gw and thus i would expect the ping response to
arrive. it doesn't.
in short, yes the dev-gw knows the route back and appears to use it
correctly. it's possible that the returning packet is not an icmp
echo-reply, of course ... although i'm pretty sure i checked that on
the remote side ... i'll double check it.
--
t
t
w
