I'm trying to set up a GRE tunnel between two 2.2.9 boxes, and I'm having a few problems which seem to be caused by a NAT device (Cisco 675 DSL router) stuck between the two tunnel endpoints. From what I can see, tunnel packets are making it through the NAT, but the Linux box on one end can't seem to decide which tunnel to associate the packets with. Watching with tcpdump, I can see pings leaving the box behind the NAT, making it to the other end, being decapsulated, replied to, and re-encapsulated, forwarded back through the NAT, received (still inside the GRE tunnel) at the destination system, and then dropped on the ground for some reason. A few details: End 1 is at work, with a single Ethernet, several modems, and kernel 2.2.9. The tunnel endpoint is configured like this: ip tunnel add tunnel-laird mode gre remote 216.160.109.16 ip addr add 206.253.194.149 dev tunnel-laird ip link set dev tunnel-laird up ip route add 206.253.199.129 dev tunnel-laird where 'ip' is ANK's iproute2 program, of course. The other end of the tunnel is configured identically, except for the IP addresses involved. The other end, at home, has two Ethernet interfaces, with eth0 connected to my home network and eth1 connected (via crossover cable) to the Cisco 675 that I'm using to connect to DSL. The 675 has a single IP address assigned to it, and essentially masquarades my office network behind it. I have it set up to forward all IP protocol 47 (GRE) packets to my Linux router. tcpdump on the Linux box shows that GRE packets are being passed through the 675 correctly. If I ping from my home box to the other tunnel endpoint, the ping packet (encapsulated in GRE) makes it through the NAT (having the tunnel wrapper's IP source changed from 10.0.0.20 to 216.160.109.16), is received correctly by the far end of the tunnel, which happily accepts it (even though the source IP has changed), replies, and sends the reply in another GRE packet, with source 206.253.194.149 and destination 216.160.109.16. This is received through the NAT (with the dest address changed to 10.0.0.20, which is assigned to eth1 on my Linux router) and delivered to the Linux box's eth1 interface. I can't see what happens to the packet after this -- it appears to be dropped silently on the ground. I can't find any error counters that increase because of this. The source in ip_gre.c suggests that, if all else fails, the tunnel packet will be received by 'gre0'. I did a 'ip link dev gre0 up', and tried assigning several different IP addresses to the device, all with no luck. As an experiment, I brought up a direct PPP (over modem) link between the two tunnel endpoints and reconfigured the tunnel to go over the modem link. It worked perfectly, with both ends receiving packets correctly and replying to them as needed. Switching back to running the tunnel over the DSL/NAT link broke things again. Interesingly enough, I was able to run the tunnel with the uplink side over DSL and the downlink side over the modem. It cut the RTT in half, but isn't really very useful -- I need the bandwidth on the downlink side, unfortunately. Does anyone have any configuration and/or patching suggestions on how to get this to work? Scott - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED]
