Re: [LARTC] GRE tunnel wierdness
David Lamparter <[EMAIL PROTECTED]> 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.comeast.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 LOGall -- 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 LOGall -- 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.comeast.somenet.com ACCEPT all -- anywhere anywhere ACCEPT all -- somenet.com somenet.com LOGall -- anywhere anywhere LOG level info prefix `FIREWALL: Filter-OUTPUT ' ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] GRE tunnel wierdness
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] GRE tunnel wierdness
David Lamparter <[EMAIL PROTECTED]> 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] GRE tunnel wierdness
Hi, Steve M Bibayoff schrieb: > internal infaces on linux boxes eth0 on x.x.x.1neta=192.168.0.0/24 > netb=192.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.00.0.0.0255.255.255.0 U 0 00 eth1 > 192.168.0.00.0.0.0255.255.255.0 U 0 00 netb [...] > 192.168.1.00.0.0.0255.255.255.0 U 0 00 eth1 > 192.168.1.00.0.0.0255.255.255.0 U 0 00 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] GRE tunnel wierdness
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=192.168.0.0/24 netb=192.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 DestinationGatewayGenmask Flags Metric RefUse Iface a.b.c.w0.0.0.0255.255.255.248 U 0 00 eth0 192.168.1.00.0.0.0255.255.255.0 U 0 00 netb 192.168.0.00.0.0.0255.255.255.0 U 0 00 eth1 192.168.0.00.0.0.0255.255.255.0 U 0 00 netb 127.0.0.0 0.0.0.0255.0.0.0 U 0 00 lo 0.0.0.0a.b.c.x0.0.0.0 UG0 00 eth0 [west]# route -n Kernel IP routing table DestinationGatewayGenmask Flags Metric RefUse Iface f.g.h.y0.0.0.0255.255.255.248 U 0 00 eth0 192.168.1.00.0.0.0255.255.255.0 U 0 00 eth1 192.168.1.00.0.0.0255.255.255.0 U 0 00 neta 192.168.0.00.0.0.0255.255.255.0 U 0 00 neta 127.0.0.0 0.0.0.0255.0.0.0 U 0 00 lo 0.0.0.0f.g.h.z0.0.0.0 UG0 00 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
