Hello!
I am trying to do some tests with tunneling, but I can see the GRE
packets incoming, but in a wrong interface...
My config:
ip tunnel add tunnel0 mode gre remote REMOTE_INET_ADDRESS local
LOCAL_INET_ADRESS ttl 255
ip link set tunnel0 up
ip addr add 172.16.1.1 peer 172.16.1.2 dev tunnel0
ip route add 172.16.1.0/24 dev tunnel0
This config is made in one side of tunnel, in a linux box. This linux
box is behind a router. This router is forwarding all gre traffic to a
ethernet interface of the router. Here is the ifconfig:
eth0 Link encap:Ethernet HWaddr 00:80:5A:61:5B:11
inet addr:192.168.21.39 Bcast:192.168.21.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53857 errors:0 dropped:0 overruns:0 frame:0
TX packets:56295 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47236709 (45.0 MiB) TX bytes:8009011 (7.6 MiB)
Interrupt:16 Base address:0xa000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2745 errors:0 dropped:0 overruns:0 frame:0
TX packets:2745 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:269767 (263.4 KiB) TX bytes:269767 (263.4 KiB)
tunnel0 Link encap:UNSPEC HWaddr
58-02-C3-75-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.1.1 P-t-P:172.16.1.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:1297 dropped:0 overruns:0 carrier:1297
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
I can see the GRE packets on eth0, but I can''t see on tunnel0 how can I
do to redirect gre packets to tunnel0 ??
Thank you!
-------------------------------------------------------------------------
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
Adrian Chapela wrote:> > I can see the GRE packets on eth0, but I can''t see on tunnel0 how can I > do to redirect gre packets to tunnel0 ??You are mis-understanding how the GRE tunnel works! The GRE packets go in and out of eth0; the tunneled packets are the ones that go in and out of tunnel0. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Adrian Chapela wrote:>I can see the GRE packets on eth0, but I can''t see on tunnel0 how can I >do to redirect gre packets to tunnel0 ??It''s my understanding that you should see encapsulated packet on eth0 - that is where the real packets are sent/delivered over the wire. Once received, the unencapsulated packets should then appear to have come via tunnel0. Sent packets are routed via tunnel0, but they are then encapsulated and sent out via eth0. ------------------------------------------------------------------------- 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
Tom Eastep escribió:> Adrian Chapela wrote: > >> >> I can see the GRE packets on eth0, but I can''t see on tunnel0 how can >> I do to redirect gre packets to tunnel0 ?? > > You are mis-understanding how the GRE tunnel works! The GRE packets go > in and out of eth0; the tunneled packets are the ones that go in and > out of tunnel0.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 ??> > -Tom > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- 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
Simon Hobson escribió:> Adrian Chapela wrote: > > >> I can see the GRE packets on eth0, but I can''t see on tunnel0 how can I >> do to redirect gre packets to tunnel0 ?? >> > > It''s my understanding that you should see encapsulated packet on eth0 > - that is where the real packets are sent/delivered over the wire. > Once received, the unencapsulated packets should then appear to have > come via tunnel0. > > Sent packets are routed via tunnel0, but they are then encapsulated > and sent out via eth0. >Yes, this is what I think> > ------------------------------------------------------------------------- > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------- 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
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. 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 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
Simon Hobson escribió:> 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)> 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 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------- 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
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
Simon Hobson escribió:> 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 ... >This is the encapsulating 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 the response: 12:56:16.397802 IP semsor10.local > 77.209.87.193: ICMP semsor10.local protocol 47 port 2048 unreachable, length 116 OK, I think I read some wrong... Now, after your explaination I think you are right, the encapsulating packet couldn''t be delivered...now the answer is why ?? The encapsulting packet is received in eth0, because my router is sending all traffic there... but Why this interface isn''t forwarding this packet to the right interface ? I have ip_forward to 1, I don''t understand...> >> > 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'' ... >Yes, this is a problem of my explanation: Remote internet address: 77.209.87.193 Tunnel Lan Network: 172.16.1.0/24> 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. >Need you some other information ??> 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------- 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
Adrian Chapela wrote:> Simon Hobson escribió: >> 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 ... >> > This is the encapsulating 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 the response: > > 12:56:16.397802 IP semsor10.local > 77.209.87.193: ICMP semsor10.local > protocol 47 port 2048 unreachable, length 116 > > OK, I think I read some wrong... Now, after your explaination I think > you are right, the encapsulating packet couldn''t be delivered...now the > answer is why ?? > > The encapsulting packet is received in eth0, because my router is > sending all traffic there... but Why this interface isn''t forwarding > this packet to the right interface ? > > I have ip_forward to 1, I don''t understand...Look at your log. I suspect that you haven''t defined tunnel0 and the remote subnet properly to Shorewall and that the ping request it getting rejected. Once again: http://www.shorewall.net/IPIP.htm gives explicit instructions for configuring IPIP and GRE tunnels in Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
2008/4/25 Adrian Chapela <achapela.rexistros@gmail.com>:> Hello! > > I am trying to do some tests with tunneling, but I can see the GRE packets > incoming, but in a wrong interface... > > My config: > > ip tunnel add tunnel0 mode gre remote REMOTE_INET_ADDRESS local > LOCAL_INET_ADRESS ttl 255I solved my problem!! I am doing a bad config here, the LOCAL_INET_ADDRESS must be my LAN address because the linux box is behind a router. This was my problem, the translation is made by router. When I redirected all gre traffic to my linux box, I forgot this redirection is a NAT translation. Obviously a internet router can´t routing to a private lan, only do a internet -> LAN translation... I am so stupid ?? JEJE In the basic was the answer and you opened my eyes saying "re read". Thank you!> > ip link set tunnel0 up > ip addr add 172.16.1.1 peer 172.16.1.2 dev tunnel0 > ip route add 172.16.1.0/24 dev tunnel0 > > This config is made in one side of tunnel, in a linux box. This linux box > is behind a router. This router is forwarding all gre traffic to a ethernet > interface of the router. Here is the ifconfig: > > eth0 Link encap:Ethernet HWaddr 00:80:5A:61:5B:11 > inet addr:192.168.21.39 Bcast:192.168.21.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:53857 errors:0 dropped:0 overruns:0 frame:0 > TX packets:56295 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:47236709 (45.0 MiB) TX bytes:8009011 (7.6 MiB) > Interrupt:16 Base address:0xa000 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:2745 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2745 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:269767 (263.4 KiB) TX bytes:269767 (263.4 KiB) > > tunnel0 Link encap:UNSPEC HWaddr > 58-02-C3-75-00-00-00-00-00-00-00-00-00-00-00-00 > inet addr:172.16.1.1 P-t-P:172.16.1.2 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:1297 dropped:0 overruns:0 carrier:1297 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > I can see the GRE packets on eth0, but I can''t see on tunnel0 how can I do > to redirect gre packets to tunnel0 ?? > > Thank you! >------------------------------------------------------------------------- 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
Adrián Ebay wrote:>I solved my problem!! I am doing a bad config >here, the LOCAL_INET_ADDRESS must be my LAN >address because the linux box is behind a >router. This was my problem, the translation is >made by router. When I redirected all gre >traffic to my linux box, I forgot this >redirection is a NAT translation. Obviously a >internet router can´t routing to a private lan, >only do a internet -> LAN translation... > >I am so stupid ??Not really, it''s an easy mistake to make when setting up things like this - trying to remember where you put the local (private) address and where to put the public address. I''ve done it myself - and as you say, you feel so stupid when you finally realise :-( You''re not the first, and I doubt if you''ll be the last ! ------------------------------------------------------------------------- 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