Reply on same interface as incoming?

Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
42
down vote
favorite
I have a system with two interfaces. Both interfaces are connected to the internet. One of them is set as the default route; a side effect of this is that if a packet comes in on the non-default-route interface, the reply is sent back through the default route interface. Is there a way to use iptables (or something else) to track the connection and send the reply back through the interface it came from?
linux iptables routing
add a comment |Â
up vote
42
down vote
favorite
I have a system with two interfaces. Both interfaces are connected to the internet. One of them is set as the default route; a side effect of this is that if a packet comes in on the non-default-route interface, the reply is sent back through the default route interface. Is there a way to use iptables (or something else) to track the connection and send the reply back through the interface it came from?
linux iptables routing
add a comment |Â
up vote
42
down vote
favorite
up vote
42
down vote
favorite
I have a system with two interfaces. Both interfaces are connected to the internet. One of them is set as the default route; a side effect of this is that if a packet comes in on the non-default-route interface, the reply is sent back through the default route interface. Is there a way to use iptables (or something else) to track the connection and send the reply back through the interface it came from?
linux iptables routing
I have a system with two interfaces. Both interfaces are connected to the internet. One of them is set as the default route; a side effect of this is that if a packet comes in on the non-default-route interface, the reply is sent back through the default route interface. Is there a way to use iptables (or something else) to track the connection and send the reply back through the interface it came from?
linux iptables routing
edited Nov 29 '10 at 23:19
Gilles
501k1169851511
501k1169851511
asked Nov 29 '10 at 22:56
Shawn J. Goff
27.9k17103132
27.9k17103132
add a comment |Â
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
45
down vote
accepted
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2
The above doesn't require any packet marking with ipfilter. It works because the outgoing (reply) packets will have the IP address that was originally used to connect to the 2nd interface as the source (from) address on the outgoing packet.
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
For me it worked only when I left out thedevparam in theip rulecommand, so runningip rule add from <interface_IP> table isp2
â cdauth
Dec 13 '15 at 17:09
2
You can make these be created when the interface goes up by addingup ip rule add from <interface_IP> table isp2andup ip route add default via <gateway_IP> dev ppp0 table isp2to your /etc/network/interfaces under the relevant interface.
â g.rocket
Apr 5 '16 at 4:59
2
I had to removedev <interface>fromip ruleto get it to work on my box. If IâÂÂm understanding right,dev <interface>was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.
â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
 |Â
show 3 more comments
up vote
6
down vote
The following commands create an alternate routing table via eth1 for packets that have the mark 1 (except packets to localhost). The ip command is from the iproute2 suite (Ubuntu: iproute Install iproute http://bit.ly/software-small, iproute-doc Install iproute-doc http://bit.ly/software-small).
ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1
The other half of the job is recognizing packets that must get the mark 1; then use iptables -t mangle -A OUTPUT ⦠-j MARK --set-mark 1 on these packets to have them routed through routing table 1. I think the following should do it (replace 1.2.3.4 by the address of the non-default-route interface):
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1
I'm not sure if that's enough, maybe another rule is needed on the incoming packets to tell the conntrack module to track them.
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
add a comment |Â
up vote
2
down vote
I had issues with the locally generated packets with the solution suggested by Peter, I've found that the following corrects that:
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2
Regards.
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
add a comment |Â
up vote
2
down vote
I'm assuming you are running Linux and, further, that you are utilising a RedHat/CentOS-based distribution. Other Unix's and distributions will require similar steps - but the details will be different.
Start by testing (note that this is very similar to @Peter's answer. I am assuming the following:
- eno0 is isp0 and has the overall default gateway
- eno1 is isp1 and has the IP/range 192.168.1.2/24 with gateway 192.168.1.1
The commands are as follows:
$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1
The firewall is not involved in any way. Reply packets would always have been sent from the correct IP - but previously were being sent out via the wrong interface. Now these packets from the correct IP will be sent via the correct interface.
Assuming the above worked, you can now make the rule and route changes permanent. This depends on what version of Unix you are using. As before, I'm assuming a RH/CentOS-based Linux distribution.
$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1
Test that the network change is permanent:
$ ifdown eno1 ; ifup eno1
If that didn't work, on the later versions of RH/CentOS you also need to do go with one of two options:
- Don't use the default NetworkManager.service; Use network.service instead. I haven't explored the exact steps needed for this. I would imagine it involves the standard chkconfig or systemctl commands to enable/disable services.
- Install the NetworkManager-dispatcher-routing-rules package
Personally I prefer installing the rules package as it is the simpler more supported approach:
$ yum install NetworkManager-dispatcher-routing-rules
Another strong recommendation is to enable arp filtering as this prevents other related issues with dual network configurations. With RH/CentOS, add the following content to the /etc/sysctl.conf file:
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
add a comment |Â
up vote
-2
down vote
The syntax seems to have changed from
ip rule add from dev <interface> table isp2 priority 1000
to
ip rule add iif 'interface' table isp2 priority 1000
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
45
down vote
accepted
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2
The above doesn't require any packet marking with ipfilter. It works because the outgoing (reply) packets will have the IP address that was originally used to connect to the 2nd interface as the source (from) address on the outgoing packet.
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
For me it worked only when I left out thedevparam in theip rulecommand, so runningip rule add from <interface_IP> table isp2
â cdauth
Dec 13 '15 at 17:09
2
You can make these be created when the interface goes up by addingup ip rule add from <interface_IP> table isp2andup ip route add default via <gateway_IP> dev ppp0 table isp2to your /etc/network/interfaces under the relevant interface.
â g.rocket
Apr 5 '16 at 4:59
2
I had to removedev <interface>fromip ruleto get it to work on my box. If IâÂÂm understanding right,dev <interface>was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.
â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
 |Â
show 3 more comments
up vote
45
down vote
accepted
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2
The above doesn't require any packet marking with ipfilter. It works because the outgoing (reply) packets will have the IP address that was originally used to connect to the 2nd interface as the source (from) address on the outgoing packet.
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
For me it worked only when I left out thedevparam in theip rulecommand, so runningip rule add from <interface_IP> table isp2
â cdauth
Dec 13 '15 at 17:09
2
You can make these be created when the interface goes up by addingup ip rule add from <interface_IP> table isp2andup ip route add default via <gateway_IP> dev ppp0 table isp2to your /etc/network/interfaces under the relevant interface.
â g.rocket
Apr 5 '16 at 4:59
2
I had to removedev <interface>fromip ruleto get it to work on my box. If IâÂÂm understanding right,dev <interface>was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.
â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
 |Â
show 3 more comments
up vote
45
down vote
accepted
up vote
45
down vote
accepted
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2
The above doesn't require any packet marking with ipfilter. It works because the outgoing (reply) packets will have the IP address that was originally used to connect to the 2nd interface as the source (from) address on the outgoing packet.
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2
The above doesn't require any packet marking with ipfilter. It works because the outgoing (reply) packets will have the IP address that was originally used to connect to the 2nd interface as the source (from) address on the outgoing packet.
edited Aug 18 '16 at 9:44
galgalesh
1206
1206
answered Oct 26 '11 at 19:10
Peter
46652
46652
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
For me it worked only when I left out thedevparam in theip rulecommand, so runningip rule add from <interface_IP> table isp2
â cdauth
Dec 13 '15 at 17:09
2
You can make these be created when the interface goes up by addingup ip rule add from <interface_IP> table isp2andup ip route add default via <gateway_IP> dev ppp0 table isp2to your /etc/network/interfaces under the relevant interface.
â g.rocket
Apr 5 '16 at 4:59
2
I had to removedev <interface>fromip ruleto get it to work on my box. If IâÂÂm understanding right,dev <interface>was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.
â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
 |Â
show 3 more comments
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
For me it worked only when I left out thedevparam in theip rulecommand, so runningip rule add from <interface_IP> table isp2
â cdauth
Dec 13 '15 at 17:09
2
You can make these be created when the interface goes up by addingup ip rule add from <interface_IP> table isp2andup ip route add default via <gateway_IP> dev ppp0 table isp2to your /etc/network/interfaces under the relevant interface.
â g.rocket
Apr 5 '16 at 4:59
2
I had to removedev <interface>fromip ruleto get it to work on my box. If IâÂÂm understanding right,dev <interface>was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.
â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
6
6
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
Wow, this is exactly what I was looking for. In case anyone is looking, for RH-based distros, you can put the relevant rule and route commands in files named 'rule-eth0' or 'route-eth0' (for example) which will be added or removed on ifup/ifdown. Place these files alongside the ifcfg-eth0 file. For IPv6, there is 'route6-eth0' functionality built in, but no 'rule6-eth0' built in (yet).
â Kyle Brantley
Dec 30 '11 at 3:58
9
9
For me it worked only when I left out the
dev param in the ip rule command, so running ip rule add from <interface_IP> table isp2â cdauth
Dec 13 '15 at 17:09
For me it worked only when I left out the
dev param in the ip rule command, so running ip rule add from <interface_IP> table isp2â cdauth
Dec 13 '15 at 17:09
2
2
You can make these be created when the interface goes up by adding
up ip rule add from <interface_IP> table isp2 and up ip route add default via <gateway_IP> dev ppp0 table isp2 to your /etc/network/interfaces under the relevant interface.â g.rocket
Apr 5 '16 at 4:59
You can make these be created when the interface goes up by adding
up ip rule add from <interface_IP> table isp2 and up ip route add default via <gateway_IP> dev ppp0 table isp2 to your /etc/network/interfaces under the relevant interface.â g.rocket
Apr 5 '16 at 4:59
2
2
I had to remove
dev <interface> from ip rule to get it to work on my box. If IâÂÂm understanding right, dev <interface> was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.â binki
Oct 2 '16 at 3:52
I had to remove
dev <interface> from ip rule to get it to work on my box. If IâÂÂm understanding right, dev <interface> was filtering out packets which were somehow set on the wrong interface which needed to be wrested over to the correct interface by the overridden route but the rule filtering by interface was preventing that from happening.â binki
Oct 2 '16 at 3:52
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
I've tried this on my home machine and it works perfectly (with dev <interface> removed), but I can't for the life of me get it working on a dedicated server I rent.
â goji
Nov 8 '16 at 7:34
 |Â
show 3 more comments
up vote
6
down vote
The following commands create an alternate routing table via eth1 for packets that have the mark 1 (except packets to localhost). The ip command is from the iproute2 suite (Ubuntu: iproute Install iproute http://bit.ly/software-small, iproute-doc Install iproute-doc http://bit.ly/software-small).
ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1
The other half of the job is recognizing packets that must get the mark 1; then use iptables -t mangle -A OUTPUT ⦠-j MARK --set-mark 1 on these packets to have them routed through routing table 1. I think the following should do it (replace 1.2.3.4 by the address of the non-default-route interface):
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1
I'm not sure if that's enough, maybe another rule is needed on the incoming packets to tell the conntrack module to track them.
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
add a comment |Â
up vote
6
down vote
The following commands create an alternate routing table via eth1 for packets that have the mark 1 (except packets to localhost). The ip command is from the iproute2 suite (Ubuntu: iproute Install iproute http://bit.ly/software-small, iproute-doc Install iproute-doc http://bit.ly/software-small).
ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1
The other half of the job is recognizing packets that must get the mark 1; then use iptables -t mangle -A OUTPUT ⦠-j MARK --set-mark 1 on these packets to have them routed through routing table 1. I think the following should do it (replace 1.2.3.4 by the address of the non-default-route interface):
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1
I'm not sure if that's enough, maybe another rule is needed on the incoming packets to tell the conntrack module to track them.
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
add a comment |Â
up vote
6
down vote
up vote
6
down vote
The following commands create an alternate routing table via eth1 for packets that have the mark 1 (except packets to localhost). The ip command is from the iproute2 suite (Ubuntu: iproute Install iproute http://bit.ly/software-small, iproute-doc Install iproute-doc http://bit.ly/software-small).
ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1
The other half of the job is recognizing packets that must get the mark 1; then use iptables -t mangle -A OUTPUT ⦠-j MARK --set-mark 1 on these packets to have them routed through routing table 1. I think the following should do it (replace 1.2.3.4 by the address of the non-default-route interface):
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1
I'm not sure if that's enough, maybe another rule is needed on the incoming packets to tell the conntrack module to track them.
The following commands create an alternate routing table via eth1 for packets that have the mark 1 (except packets to localhost). The ip command is from the iproute2 suite (Ubuntu: iproute Install iproute http://bit.ly/software-small, iproute-doc Install iproute-doc http://bit.ly/software-small).
ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1
The other half of the job is recognizing packets that must get the mark 1; then use iptables -t mangle -A OUTPUT ⦠-j MARK --set-mark 1 on these packets to have them routed through routing table 1. I think the following should do it (replace 1.2.3.4 by the address of the non-default-route interface):
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1
I'm not sure if that's enough, maybe another rule is needed on the incoming packets to tell the conntrack module to track them.
answered Nov 29 '10 at 23:16
Gilles
501k1169851511
501k1169851511
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
add a comment |Â
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
Nice. I forgot all about marking. That should get me there.
â Shawn J. Goff
Nov 30 '10 at 2:33
add a comment |Â
up vote
2
down vote
I had issues with the locally generated packets with the solution suggested by Peter, I've found that the following corrects that:
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2
Regards.
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
add a comment |Â
up vote
2
down vote
I had issues with the locally generated packets with the solution suggested by Peter, I've found that the following corrects that:
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2
Regards.
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I had issues with the locally generated packets with the solution suggested by Peter, I've found that the following corrects that:
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2
Regards.
I had issues with the locally generated packets with the solution suggested by Peter, I've found that the following corrects that:
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2
Regards.
answered Sep 23 '16 at 7:31
Héctor Sánchez
211
211
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
add a comment |Â
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
Tried so much but nothing worked at my scenario, except this.. many thanks.
â agaggi
May 31 '17 at 20:48
add a comment |Â
up vote
2
down vote
I'm assuming you are running Linux and, further, that you are utilising a RedHat/CentOS-based distribution. Other Unix's and distributions will require similar steps - but the details will be different.
Start by testing (note that this is very similar to @Peter's answer. I am assuming the following:
- eno0 is isp0 and has the overall default gateway
- eno1 is isp1 and has the IP/range 192.168.1.2/24 with gateway 192.168.1.1
The commands are as follows:
$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1
The firewall is not involved in any way. Reply packets would always have been sent from the correct IP - but previously were being sent out via the wrong interface. Now these packets from the correct IP will be sent via the correct interface.
Assuming the above worked, you can now make the rule and route changes permanent. This depends on what version of Unix you are using. As before, I'm assuming a RH/CentOS-based Linux distribution.
$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1
Test that the network change is permanent:
$ ifdown eno1 ; ifup eno1
If that didn't work, on the later versions of RH/CentOS you also need to do go with one of two options:
- Don't use the default NetworkManager.service; Use network.service instead. I haven't explored the exact steps needed for this. I would imagine it involves the standard chkconfig or systemctl commands to enable/disable services.
- Install the NetworkManager-dispatcher-routing-rules package
Personally I prefer installing the rules package as it is the simpler more supported approach:
$ yum install NetworkManager-dispatcher-routing-rules
Another strong recommendation is to enable arp filtering as this prevents other related issues with dual network configurations. With RH/CentOS, add the following content to the /etc/sysctl.conf file:
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
add a comment |Â
up vote
2
down vote
I'm assuming you are running Linux and, further, that you are utilising a RedHat/CentOS-based distribution. Other Unix's and distributions will require similar steps - but the details will be different.
Start by testing (note that this is very similar to @Peter's answer. I am assuming the following:
- eno0 is isp0 and has the overall default gateway
- eno1 is isp1 and has the IP/range 192.168.1.2/24 with gateway 192.168.1.1
The commands are as follows:
$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1
The firewall is not involved in any way. Reply packets would always have been sent from the correct IP - but previously were being sent out via the wrong interface. Now these packets from the correct IP will be sent via the correct interface.
Assuming the above worked, you can now make the rule and route changes permanent. This depends on what version of Unix you are using. As before, I'm assuming a RH/CentOS-based Linux distribution.
$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1
Test that the network change is permanent:
$ ifdown eno1 ; ifup eno1
If that didn't work, on the later versions of RH/CentOS you also need to do go with one of two options:
- Don't use the default NetworkManager.service; Use network.service instead. I haven't explored the exact steps needed for this. I would imagine it involves the standard chkconfig or systemctl commands to enable/disable services.
- Install the NetworkManager-dispatcher-routing-rules package
Personally I prefer installing the rules package as it is the simpler more supported approach:
$ yum install NetworkManager-dispatcher-routing-rules
Another strong recommendation is to enable arp filtering as this prevents other related issues with dual network configurations. With RH/CentOS, add the following content to the /etc/sysctl.conf file:
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I'm assuming you are running Linux and, further, that you are utilising a RedHat/CentOS-based distribution. Other Unix's and distributions will require similar steps - but the details will be different.
Start by testing (note that this is very similar to @Peter's answer. I am assuming the following:
- eno0 is isp0 and has the overall default gateway
- eno1 is isp1 and has the IP/range 192.168.1.2/24 with gateway 192.168.1.1
The commands are as follows:
$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1
The firewall is not involved in any way. Reply packets would always have been sent from the correct IP - but previously were being sent out via the wrong interface. Now these packets from the correct IP will be sent via the correct interface.
Assuming the above worked, you can now make the rule and route changes permanent. This depends on what version of Unix you are using. As before, I'm assuming a RH/CentOS-based Linux distribution.
$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1
Test that the network change is permanent:
$ ifdown eno1 ; ifup eno1
If that didn't work, on the later versions of RH/CentOS you also need to do go with one of two options:
- Don't use the default NetworkManager.service; Use network.service instead. I haven't explored the exact steps needed for this. I would imagine it involves the standard chkconfig or systemctl commands to enable/disable services.
- Install the NetworkManager-dispatcher-routing-rules package
Personally I prefer installing the rules package as it is the simpler more supported approach:
$ yum install NetworkManager-dispatcher-routing-rules
Another strong recommendation is to enable arp filtering as this prevents other related issues with dual network configurations. With RH/CentOS, add the following content to the /etc/sysctl.conf file:
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
I'm assuming you are running Linux and, further, that you are utilising a RedHat/CentOS-based distribution. Other Unix's and distributions will require similar steps - but the details will be different.
Start by testing (note that this is very similar to @Peter's answer. I am assuming the following:
- eno0 is isp0 and has the overall default gateway
- eno1 is isp1 and has the IP/range 192.168.1.2/24 with gateway 192.168.1.1
The commands are as follows:
$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1
The firewall is not involved in any way. Reply packets would always have been sent from the correct IP - but previously were being sent out via the wrong interface. Now these packets from the correct IP will be sent via the correct interface.
Assuming the above worked, you can now make the rule and route changes permanent. This depends on what version of Unix you are using. As before, I'm assuming a RH/CentOS-based Linux distribution.
$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1
Test that the network change is permanent:
$ ifdown eno1 ; ifup eno1
If that didn't work, on the later versions of RH/CentOS you also need to do go with one of two options:
- Don't use the default NetworkManager.service; Use network.service instead. I haven't explored the exact steps needed for this. I would imagine it involves the standard chkconfig or systemctl commands to enable/disable services.
- Install the NetworkManager-dispatcher-routing-rules package
Personally I prefer installing the rules package as it is the simpler more supported approach:
$ yum install NetworkManager-dispatcher-routing-rules
Another strong recommendation is to enable arp filtering as this prevents other related issues with dual network configurations. With RH/CentOS, add the following content to the /etc/sysctl.conf file:
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
answered Aug 11 '17 at 9:54
zaTricky
20327
20327
add a comment |Â
add a comment |Â
up vote
-2
down vote
The syntax seems to have changed from
ip rule add from dev <interface> table isp2 priority 1000
to
ip rule add iif 'interface' table isp2 priority 1000
add a comment |Â
up vote
-2
down vote
The syntax seems to have changed from
ip rule add from dev <interface> table isp2 priority 1000
to
ip rule add iif 'interface' table isp2 priority 1000
add a comment |Â
up vote
-2
down vote
up vote
-2
down vote
The syntax seems to have changed from
ip rule add from dev <interface> table isp2 priority 1000
to
ip rule add iif 'interface' table isp2 priority 1000
The syntax seems to have changed from
ip rule add from dev <interface> table isp2 priority 1000
to
ip rule add iif 'interface' table isp2 priority 1000
edited Apr 28 '17 at 1:02
ddnomad
9541622
9541622
answered Apr 27 '17 at 23:30
user228993
1
1
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4420%2freply-on-same-interface-as-incoming%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password