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
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/
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.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/
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 netaTried 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/
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/
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/