Adrian Chapela wrote: > >> Yes, I know... but Why can't I see the icmp packets goin throw the >>> tunnel interface ?? I see a GRE packet-- > 12:56:16.397645 IP >>> 77.209.87.193 > semsor10.local: GREv0, length 88: IP 172.16.1.2 > >>> 172.16.1.1: ICMP echo request, id 63499, seq 151, length 64 >>> >>> This is a encapsuled packet of a ping from 172.16.1.2 to 172.16.1.1 >>> and this is the response: >>> >>> 12:56:16.397802 IP semsor10.local > 77.209.87.193: ICMP semsor10.local >>> protocol 47 port 2048 unreachable, length 116 >>> >>> This is the problem... Why is the eth0 responding an answer to another >>> interface ?? >>> >> >> It isn't ! interfaces do not "respond to another interface" - they >> only send packets given them by the protocol stacks above. >> 77.209.87.193 is not flagged as being at the other end of tunnel0, >> therefore it is routed via eth0 - and if you look, it is NOT a >> response to the ping, it is a "destination unreachable" response to >> the encapsulated packet. >> >Yes, but this "destination unreachable" isn't encapsulated in a GRE >packet and it is generating (I think...) on the eth0)
No go back and read again. The inbound encapsulated packet could not be delivered, therefore a destination unreachable replay was sent back in response. It was not the tunnelled packet that couldn't be delivered, it was the encapsulating packet. More below ... > > What have you set as the public address for the other end of the >> tunnel (REMOTE_INET_ADDRESS in your original message) ? Is it > > 77.209.87.193 or 172.16.1.2 ? >> > >This is the REMOTE_INET_ADDRESS, 172.16.1.0/24 is the lan for the >tunnel. What do you think I am doing wrong ? This sentence does not make sense - 172.16.1.0/24 is not an IP address, it's a subnet. I've not done any GRE, so this is 'educated guesswork' ... You CANNOT send a packet to 172.16.1.2 across the internet, so 172.16.1.2 cannot be the remote device address - so the remote device address would have to be 77.209.87.193. Further, I assume that GRE checks the source address of the incoming packets - it would be very insecure if anyone could spoof packets from anywhere on the internet, so if you set the wrong remote device address, it will reject the incoming packet. That would be my guess, but since you didn't answer the question I don't know. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
