dslrouters have own externat ip-addresses and portforwarding for some ports, example http… eth0 is default route on suse1. on suse2, http from 10.0.0.2(suse1) works fine…
when i try to access ext_ip2 via http from internet, it cant get the page from suse1. when changing portforwarding from dslrouter2 to suse2, everything works without problems. on suse1, kernel logs “martial source” when trying http from ext_ip2… what is a problem? ext_ip1 http works fine. both eth0 and eth1 are on dmz on suse1:s susefirewall and that dmz on susefirewall has http enabled.
Your machine “suse1” (apache?) will use the default route through eth0 to answer any request coming in through eth1. This can’t work. What are you trying to do?
i need that suse1 to reply to that eth where request is coming… so if request comes from eth0, it replies to eth0 and if request comes from eth1 it will reply to eth1… this works from int ip:s but not with ext ip:s which requests are coming throught eth1. protocols which i need is http and ssh… requests from eth0 works both, from int and ext ip:s…
this reply is not looking that eth where request have come but it allways use routing table for eth:s to reply? so if requesting ip is external, reply goes to eth0 and if it is in range of int ip which belongs to eth1 mask, it replies to eth1?
yes, i’ve done some tests now… and it is true, that routing table denies that reply to eth1 if requesting ip is out of its mask… i used tcpdump and it shows that linux is not answering to these seq-packets which are coming from eth1 and are out of its routing mask. when i put that eth1 to default route, it worked for eth1, but then its not working with eth0. why this happens? why this can’t just reply to the same interface which is requesting?? why this routing table is used in replies? is this some kind of tcp/ip-standards bug or is this only linux-based propblem?
ip forwarding means that requests from eth0 are send to eth1 or vice versa… and thats not what i want. i just want that requests from eth0 are replied to eth0 and eth1 request are replied to eth1. i tested to set that ip forwarding on, if this would somehow block these, but no success…
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.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 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
The red line is the default route. Any packet with a destination outside of your local networks will be sent to the gateway through eth0. You can have just one default route. Only one of your NICs can have a gateway. Thats why your setup does not work as expected.
You would need policy based routing to use 2 NICs at the same time.
yes, i found that myself too,i just don’t understand why routing doesn’t understand that when packets come from one interface, these replies would go back to that interface because that socket is open on socket-layer. why this routing denies these packets to reply to different route if request has come from that different route… i understand that my computer uses that route when it is opening client-connections, but i can’t understand why that routing denies these already opened sockets… i would check that policyrouting later today if there might be some workaround for this…
I think you have the common misconception that packets have memory of where they came from and that the reply packets must go back the same route the forward packets took going out. In a multihomed situation, you must use policy based routing to make the source IP address that of the relevant interface. Hence LARTC.
i used that iproute2-script with my settings and it worked fine and now i have two nics working separately just how i wanted. there was also example of settings for bootscripts, but in opensuse there is no file like /etc/rc.d/rc.local so i put that string into /etc/rc.d/boot.local and tested reboot and it worked just fine.