All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] GRE tunnel wierdness
@ 2002-09-24 22:22 Steve M Bibayoff
  2002-09-24 22:42 ` David Lamparter
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Steve M Bibayoff @ 2002-09-24 22:22 UTC (permalink / raw)
  To: lartc

I haveing something wierd going on, can't seem to figure why. I have two
private networks (neta & netb), being masq'ed behind RH 7.3
machines(east & west). I also have iptables running on both machines. I
could ping from west to east anytime with no problem, but when I try to
ping from east to west, it doesn't go through unless I first ping from
west to east (hoepfully this is understandable the way I'm descibing
it). Here is my setup:
       ------   ------------             ------------  ------
neta---|east|---|dsl router|--internet---|dsl router|--|west|--netb
       ------   ------------             ------------  ------

internal infaces on linux boxes eth0 on x.x.x.1neta\x192.168.0.0/24
netb\x192.168.1.0/24ip rules on east:
# ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
# ip link set netb up arp on
# ip addr add 192.168.0.254/24 dev netb
# ip route add 192.168.1.0/24 dev netb
ip rules on west:
# ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
# ip link set neta up arp on
# ip addr add 192.168.1.254/24 dev neta
# ip route add 192.168.0.0/24 dev neta
[east]# route -n
Kernel IP routing table
Destination    Gateway    Genmask         Flags Metric Ref    Use Iface
a.b.c.w        0.0.0.0    255.255.255.248 U     0      0        0 eth0
192.168.1.0    0.0.0.0    255.255.255.0   U     0      0        0 netb
192.168.0.0    0.0.0.0    255.255.255.0   U     0      0        0 eth1
192.168.0.0    0.0.0.0    255.255.255.0   U     0      0        0 netb
127.0.0.0      0.0.0.0    255.0.0.0       U     0      0        0 lo
0.0.0.0        a.b.c.x    0.0.0.0         UG    0      0        0 eth0
[west]# route -n
Kernel IP routing table
Destination    Gateway    Genmask         Flags Metric Ref    Use Iface
f.g.h.y        0.0.0.0    255.255.255.248 U     0      0        0 eth0
192.168.1.0    0.0.0.0    255.255.255.0   U     0      0        0 eth1
192.168.1.0    0.0.0.0    255.255.255.0   U     0      0        0 neta
192.168.0.0    0.0.0.0    255.255.255.0   U     0      0        0 neta
127.0.0.0      0.0.0.0    255.0.0.0       U     0      0        0 lo
0.0.0.0        f.g.h.z    0.0.0.0         UG    0      0        0 eth0
Iptables are the same on both boxes except on east I open allow ports 25
80 443 and specifically block port 1003.

If I'm listening on west at neta when I first try to ping anyone on
netb, nothing is coming though unless I have just pinged from netb to
neta first.

Hopefully this isn't too confusing or long winded.

TIA

Steve


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] GRE tunnel wierdness
  2002-09-24 22:22 [LARTC] GRE tunnel wierdness Steve M Bibayoff
@ 2002-09-24 22:42 ` David Lamparter
  2002-09-25 16:32 ` Steve M Bibayoff
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: David Lamparter @ 2002-09-24 22:42 UTC (permalink / raw)
  To: lartc

Hi,
Steve M Bibayoff schrieb:
> internal infaces on linux boxes eth0 on x.x.x.1neta\x192.168.0.0/24
> netb\x192.168.1.0/24ip rules on east:
> # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
> # ip link set netb up arp on
> # ip addr add 192.168.0.254/24 dev netb
                              -^^
> # ip route add 192.168.1.0/24 dev netb
> ip rules on west:
> # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
> # ip link set neta up arp on
> # ip addr add 192.168.1.254/24 dev neta
                              -^^
> # ip route add 192.168.0.0/24 dev neta
> [east]# route -n
[...]
> 192.168.0.0    0.0.0.0    255.255.255.0   U     0      0        0 eth1
> 192.168.0.0    0.0.0.0    255.255.255.0   U     0      0        0 netb
[...]
> 192.168.1.0    0.0.0.0    255.255.255.0   U     0      0        0 eth1
> 192.168.1.0    0.0.0.0    255.255.255.0   U     0      0        0 neta
[...]
> If I'm listening on west at neta when I first try to ping anyone on
> netb, nothing is coming though unless I have just pinged from netb to
> neta first.
> 

I don't know where this ping effect comes from, but your setup is 
somewhat ... confusing.
First, you use /24 subnet masks on the tunnel interfaces ... why? This 
results in having 2 routes for your local subnet, one over eth1, and one 
over the tunnel ...

- A possible setup would be:

east:
# ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
# ip link set netb up
# ip addr add 192.168.0.254/32 peer 192.168.1.0/24 dev netb

west:
# ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
# ip link set neta up
# ip addr add 192.168.1.254/32 peer 192.168.0.0/24 dev neta

- *Or* another possibility:
east:
# ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
# ip link set netb up
# ip addr add 192.168.2.1/30 dev netb
# ip route add 192.168.1.0/24 via 192.168.2.2 dev netb

west:
# ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
# ip link set neta up
# ip addr add 192.168.2.2/30 dev neta
# ip route add 192.168.0.0/24 via 192.168.2.1 dev neta

The second possibility will work better when using some "sensible" 
software like zebra, mrouted or pimd.

Note that tunnels usually are used as point-to-point interfaces.


David Lamparter

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] GRE tunnel wierdness
  2002-09-24 22:22 [LARTC] GRE tunnel wierdness Steve M Bibayoff
  2002-09-24 22:42 ` David Lamparter
@ 2002-09-25 16:32 ` Steve M Bibayoff
  2002-09-25 16:59 ` David Lamparter
  2002-09-25 18:01 ` Steve M Bibayoff
  3 siblings, 0 replies; 5+ messages in thread
From: Steve M Bibayoff @ 2002-09-25 16:32 UTC (permalink / raw)
  To: lartc

David Lamparter <david.lamparter@t-online.de> wrote:

> I don't know where this ping effect comes from, 
> 
> east:
> # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
> # ip link set netb up
> # ip addr add 192.168.0.254/32 peer 192.168.1.0/24 dev netb
> 
> west:
> # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
> # ip link set neta up
> # ip addr add 192.168.1.254/32 peer 192.168.0.0/24 dev neta
> 
> - *Or* another possibility:
> east:
> # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255
> # ip link set netb up
> # ip addr add 192.168.2.1/30 dev netb
> # ip route add 192.168.1.0/24 via 192.168.2.2 dev netb
> 
> west:
> # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255
> # ip link set neta up
> # ip addr add 192.168.2.2/30 dev neta
> # ip route add 192.168.0.0/24 via 192.168.2.1 dev neta

Tried both of these, am still seeing this weird ping affect. If no
traffic travels over the tunnel for a while (>5 minutes) I can't get
from .0/24 neta(east) to .1/24 netb(west) till after I send some traffic 
from west to east first. Once I do that, everything else works fine.

Is there soemthing, that someone could think of, that I should check?

TIA

Steve




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] GRE tunnel wierdness
  2002-09-24 22:22 [LARTC] GRE tunnel wierdness Steve M Bibayoff
  2002-09-24 22:42 ` David Lamparter
  2002-09-25 16:32 ` Steve M Bibayoff
@ 2002-09-25 16:59 ` David Lamparter
  2002-09-25 18:01 ` Steve M Bibayoff
  3 siblings, 0 replies; 5+ messages in thread
From: David Lamparter @ 2002-09-25 16:59 UTC (permalink / raw)
  To: lartc

Steve M Bibayoff schrieb:
> Tried both of these, am still seeing this weird ping affect. If no
> traffic travels over the tunnel for a while (>5 minutes) I can't get
> from .0/24 neta(east) to .1/24 netb(west) till after I send some traffic 
> from west to east first. Once I do that, everything else works fine.
> 
> Is there soemthing, that someone could think of, that I should check?
> 

Do you have NAT / mangling / etc. running somewhere? The connection 
tracking timeout is 500 s afaik, maybe GRE is NATed on one of your gateways?

A possible explanation would be that east does SNAT on GRE packets or 
west does DNAT on GRE ... so when east tries to reach west, the packet 
is SNAT'ed or DNAT'ed and therefore doesn't reach west, but when west 
tries to reach east, connection tracking information is set up on both 
routers so it works ... until the timeout expires.

David Lamparter

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] GRE tunnel wierdness
  2002-09-24 22:22 [LARTC] GRE tunnel wierdness Steve M Bibayoff
                   ` (2 preceding siblings ...)
  2002-09-25 16:59 ` David Lamparter
@ 2002-09-25 18:01 ` Steve M Bibayoff
  3 siblings, 0 replies; 5+ messages in thread
From: Steve M Bibayoff @ 2002-09-25 18:01 UTC (permalink / raw)
  To: lartc

David Lamparter <david.lamparter@t-online.de> wrote:

> Do you have NAT / mangling / etc. running somewhere? The connection 
> tracking timeout is 500 s afaik, maybe GRE is NATed on one of your 
> gateways?
> A possible explanation would be that east does SNAT on GRE packets 
> or 
> west does DNAT on GRE ... so when east tries to reach west, the 
> packet 
> is SNAT'ed or DNAT'ed and therefore doesn't reach west, but when 
> west 
> tries to reach east, connection tracking information is set up on 
> both 
> routers so it works ... until the timeout expires.

That's is it. It actually happens when going from west to east, I just
never noticed it before.

Thanks for the clue.

Steve

ps. I know this isn't the appropiate list, but could someone see what
iptable rule needs to be changed to make this not happen(rules generated
from script found at: http://www.asgardsrealm.net/linux/firewall ).

[root@east root]# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     ipv6-auth--  anywhere             anywhere           
ACCEPT     ipv6-crypt--  anywhere             anywhere           
ACCEPT     icmp --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           state
RELATED,ESTABLISHED 
ACCEPT     all  --  east.somenet.com    east.somenet.com  
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:http 
ACCEPT     udp  --  anywhere             anywhere           udp dpt:http 
ACCEPT     tcp  --  anywhere             anywhere           tcp
dpt:re-mail-ck 
ACCEPT     udp  --  anywhere             anywhere           udp
dpt:re-mail-ck 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:51 
ACCEPT     udp  --  anywhere             anywhere           udp dpt:51 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:47 
ACCEPT     udp  --  anywhere             anywhere           udp dpt:47 
ACCEPT     udp  --  anywhere             anywhere           udp dpt:isakmp 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:http 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:https 
ACCEPT     all  --  anywhere             anywhere           
LOG        all  --  anywhere             anywhere           LOG level
info prefix `FIREWALL: Filter-INPUT ' 

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  192.168.1.0/24       192.168.0.0/24     
ACCEPT     all  --  192.168.0.0/24       192.168.1.0/24     
ACCEPT     all  --  anywhere             anywhere           state
RELATED,ESTABLISHED 
ACCEPT     all  --  192.168.2.0/24       anywhere           
ACCEPT     all  --  192.168.1.0/24       anywhere           
ACCEPT     all  --  192.168.0.0/24       anywhere           
LOG        all  --  anywhere             anywhere           LOG level
info prefix `FIREWALL: Filter-FORWARD ' 

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere           state
RELATED,ESTABLISHED 
ACCEPT     all  --  192.168.0.0/24       anywhere           
ACCEPT     all  --  192.168.1.0/24       anywhere           
ACCEPT     all  --  192.168.2.0/24       anywhere           
ACCEPT     all  --  east.somenet.com    east.somenet.com  
ACCEPT     all  --  anywhere             anywhere           
ACCEPT     all  --  somenet.com         somenet.com       
LOG        all  --  anywhere             anywhere           LOG level
info prefix `FIREWALL: Filter-OUTPUT ' 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-09-25 18:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-24 22:22 [LARTC] GRE tunnel wierdness Steve M Bibayoff
2002-09-24 22:42 ` David Lamparter
2002-09-25 16:32 ` Steve M Bibayoff
2002-09-25 16:59 ` David Lamparter
2002-09-25 18:01 ` Steve M Bibayoff

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.