* 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