All:
I am having a routing issue on a server with 2 interfaces that are
SUPPOSEDLY on 2 different networks:
one being the DMZ
the other being the internal network
So the internal interface (eth0) is also the interface with the
default route(eth0). Now, the other gateways are configured within
the /etc/sysconfig/network/ifcfg-eth-*, respectively.
On my DMZ interface (eth1), I cannot route back through my firewall to
get HTTPS traffic returned to the requestor (as indicated below)
until I change the default route to the DMZ interface (eth1).
Apparently the interface does not know how to route back through the
the eth1 interface to return the HTTPS traffic. But when I am in
traversing the network internally via SSH or HTTP everything
seemingly routes fine with both eth0 and/or eth1 - in other words I do
not have return traffic problems.
The problem above is resolved once I make the DMZ interface (eth1) the
default route, but that causes other problems that I
am not prepared, or more embarrassed to discuss.
How can my be resolved without making the DMZ interface my default
route?
freshcrap:/etc/sysconfig/network # tcpdump -i eth1:0 -vvv "(port 443
and ip host 74.198.149.2) or (dst 74.198.149.2)"
tcpdump: listening on eth1:0, link-type EN10MB (Ethernet), capture
size 96 bytes
15:18:46.102340 IP (tos 0x0, ttl 50, id 2354, offset 0, flags [DF],
proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 >
ripem.poop.org.https: S, cksum 0x905f (correct),
3124559779:3124559779(0) win 5800
OK ... The traffic is returning out of the DMZ interface, when it is the default route, to the internet because the DMZ interface is obviously the only interface that can route internet traffic back. DUH!! I need to know can I use "rp_filter" and "martian_packets" to return these packets back through the proper interface. Thanks, LDB On May 5, 2008, at 7:26 PM, LDB wrote:
All:
I am having a routing issue on a server with 2 interfaces that are SUPPOSEDLY on 2 different networks:
one being the DMZ the other being the internal network
So the internal interface (eth0) is also the interface with the default route(eth0). Now, the other gateways are configured within the /etc/sysconfig/network/ifcfg-eth-*, respectively.
On my DMZ interface (eth1), I cannot route back through my firewall to get HTTPS traffic returned to the requestor (as indicated below) until I change the default route to the DMZ interface (eth1). Apparently the interface does not know how to route back through the the eth1 interface to return the HTTPS traffic. But when I am in traversing the network internally via SSH or HTTP everything seemingly routes fine with both eth0 and/or eth1 - in other words I do not have return traffic problems.
The problem above is resolved once I make the DMZ interface (eth1) the default route, but that causes other problems that I am not prepared, or more embarrassed to discuss.
How can my be resolved without making the DMZ interface my default route?
freshcrap:/etc/sysconfig/network # tcpdump -i eth1:0 -vvv "(port 443 and ip host 74.198.149.2) or (dst 74.198.149.2)" tcpdump: listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes
15:18:46.102340 IP (tos 0x0, ttl 50, id 2354, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 > ripem.poop.org.https: S, cksum 0x905f (correct), 3124559779:3124559779(0) win 5800
15:18:49.101321 IP (tos 0x0, ttl 50, id 2355, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 > ripem.poop.org.https: S, cksum 0x8d71 (correct), 3124559779:3124559779(0) win 5800 gh 15:18:55.094981 IP (tos 0x0, ttl 50, id 2356, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 > ripem.poop.org.https: S, cksum 0x8795 (correct), 3124559779:3124559779(0) win 5800 15:19:07.095191 IP (tos 0x0, ttl 50, id 2357, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 > ripem.poop.org.https: S, cksum 0x7bdd (correct), 3124559779:3124559779(0) win 5800 4 packets captured 8 packets received by filter 0 packets dropped by kernel
freshcrap:/etc/sysconfig/network # route
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 * 255.255.255.0 U 0 0 0 eth1 192.168.19.0 * 255.255.240.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default pix-in.in.poop. 0.0.0.0 UG 0 0 0 eth0
Thanks,
LDB
-- To unsubscribe, e-mail: opensuse-networking+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-networking+help@opensuse.org
After a TCPDump analysis on the destination host, it is apparently seeing the SYNs, but not sending the ACKs. What could be the cause of it not sending back the ACKs? Thanks, LDB On May 5, 2008, at 10:25 PM, LDB wrote:
OK ... The traffic is returning out of the DMZ interface, when it is the default route, to the internet because the DMZ interface is obviously the only interface that can route internet traffic back. DUH!!
I need to know can I use "rp_filter" and "martian_packets" to return these packets back through the proper interface.
Thanks,
LDB
On May 5, 2008, at 7:26 PM, LDB wrote:
All:
I am having a routing issue on a server with 2 interfaces that are SUPPOSEDLY on 2 different networks:
one being the DMZ the other being the internal network
So the internal interface (eth0) is also the interface with the default route(eth0). Now, the other gateways are configured within the /etc/sysconfig/network/ifcfg-eth-*, respectively.
On my DMZ interface (eth1), I cannot route back through my firewall to get HTTPS traffic returned to the requestor (as indicated below) until I change the default route to the DMZ interface (eth1). Apparently the interface does not know how to route back through the the eth1 interface to return the HTTPS traffic. But when I am in traversing the network internally via SSH or HTTP everything seemingly routes fine with both eth0 and/or eth1 - in other words I do not have return traffic problems.
The problem above is resolved once I make the DMZ interface (eth1) the default route, but that causes other problems that I am not prepared, or more embarrassed to discuss.
How can my be resolved without making the DMZ interface my default route?
freshcrap:/etc/sysconfig/network # tcpdump -i eth1:0 -vvv "(port 443 and ip host 74.198.149.2) or (dst 74.198.149.2)" tcpdump: listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes
15:18:46.102340 IP (tos 0x0, ttl 50, id 2354, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512
ripem.poop.org.https: S, cksum 0x905f (correct), 3124559779:3124559779(0) win 5800
15:18:49.101321 IP (tos 0x0, ttl 50, id 2355, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 ripem.poop.org.https: S, cksum 0x8d71 (correct), 3124559779:3124559779(0) win 5800 gh 15:18:55.094981 IP (tos 0x0, ttl 50, id 2356, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 ripem.poop.org.https: S, cksum 0x8795 (correct), 3124559779:3124559779(0) win 5800 15:19:07.095191 IP (tos 0x0, ttl 50, id 2357, offset 0, flags [DF], proto: TCP (6), length: 60) 2.sub-74-198-149.myvzw.com.19512 ripem.poop.org.https: S, cksum 0x7bdd (correct), 3124559779:3124559779(0) win 5800 4 packets captured 8 packets received by filter 0 packets dropped by kernel
freshcrap:/etc/sysconfig/network # route
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 * 255.255.255.0 U 0 0 0 eth1 192.168.19.0 * 255.255.240.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default pix-in.in.poop. 0.0.0.0 UG 0 0 0 eth0
Thanks,
LDB
-- To unsubscribe, e-mail: opensuse-networking+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-networking+help@opensuse.org
On Dienstag 06 Mai 2008, LDB wrote:
All:
I am having a routing issue on a server with 2 interfaces that are SUPPOSEDLY on 2 different networks:
one being the DMZ the other being the internal network
So the internal interface (eth0) is also the interface with the default route(eth0). Now, the other gateways are configured within the /etc/sysconfig/network/ifcfg-eth-*, respectively.
On my DMZ interface (eth1), I cannot route back through my firewall to get HTTPS traffic returned to the requestor (as indicated below) until I change the default route to the DMZ interface (eth1). Apparently the interface does not know how to route back through the the eth1 interface to return the HTTPS traffic. But when I am in traversing the network internally via SSH or HTTP everything seemingly routes fine with both eth0 and/or eth1 - in other words I do not have return traffic problems.
The problem above is resolved once I make the DMZ interface (eth1) the default route, but that causes other problems that I am not prepared, or more embarrassed to discuss.
And somewhere there is the real problem hidden, you network setup looks like to have a design flaw :)
How can my be resolved without making the DMZ interface my default route?
From the informations you give, i guess setup a simple source policy routing will do the trick. ip rule add from <dmz-ip> lookup 10000 ip route add default via <default-gw> dev <dmz-iface> table 10000 ip route flush cache This makes sure, that packets with source ip <dmz-ip> routed one the <dmz-iface> to <default-gw> regards, Paul -- To unsubscribe, e-mail: opensuse-networking+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-networking+help@opensuse.org
participants (2)
-
LDB
-
Paul Zirnik