Hi All:
I have a strange problem that was described in a previous mail but I have
stripped the problem down to the following:
I have a debian based router that I have setup IPSec with GRE over top. The
tunnel addresses are 192.168.2.97 locally, the other side is 192.168.2.110. The
tunnel is 192.168.2.96/28. The end points are locally 192.168.1.97(eth1) and
192.168.1.1 the other side''s eth 1. Both local ethernet''s are
behind NAT of
course.
Now, I have ahost, 192.168.1.101 on the 192.168.1.96/28 network behind the
debbian router. Here is my routing table:
rx1000test:~# ip route show
202.42.98.1 dev ppp1 proto kernel scope link src 202.42.98.62
192.168.1.0/28 dev GDC1 scope link
192.168.1.96/28 dev eth1 scope link
default dev ppp1 scope link
This seems really simple to me, anything going to 192.168.1.0/28 must go
through tunnel GDC1. Here is the tunnel:
15: GDC1@NONE: <POINTOPOINT,NOARP,PROMISC,UP> mtu 1428 qdisc noqueue
link/gre 192.168.1.97 peer 192.168.1.1
inet 192.168.2.97 peer 192.168.2.110/28 scope global GDC1
Ok, now to check this I run tcpdump -i GDC1, tcpdump -i eth1 not tcp port 22
and I ping from 192.168.1.101 to 192.168.1.2, here is what I get:
C:\>ping 192.168.1.2 -n 2
Pinging 192.168.1.2 with 32 bytes of data:
Request timed out.
Request timed out.
Ping statistics for 192.168.1.2:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
rx1000test:~# tcpdump -i GDC1
tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked
socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on GDC1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
13:40:01.296907 IP 192.168.1.2 > 192.168.1.101: icmp 40: echo reply seq 7424
13:40:06.587157 IP 192.168.1.2 > 192.168.1.101: icmp 40: echo reply seq 7680
rx1000test:~# tcpdump -i eth1 not tcp port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:40:01.267813 IP 192.168.1.101 > 192.168.1.2: icmp 40: echo request seq
7424
13:40:06.571007 IP 192.168.1.101 > 192.168.1.2: icmp 40: echo request seq
7680
This is bizzare:
The ping to 192.168.1.2, which is clearly part of the 192.168.1.0/28 network
enters Eth1 but does does NOT go through the GDC1 tunnel on its way to
192.168.1.2....but the routing table tells us that it MUST go that way...no?
Then the replay comes back via the tunnel but never goes out eth1. eh????
I am watching /var/log/syslog and shorewall is not doing anything, but just to
make sure I stop shorewall and redo the test, exactly the same thing.
Does anyone know WHY the pings to 192.168.1.2 are not going into the GDC1
tunnel?
Does anyone know WHY the return pings do not get forwarded out eth1?
Cheers,
John
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
