Output traffic on different interfaces based on destination port
Clash Royale CLAN TAG#URR8PPP
My question is basically the same as Only allow certain outbound traffic on certain interfaces.
I have two interfaces eth1
(10.0.0.2) and wlan0
(192.168.0.2).
My default route is for eth1
.
Let's say I want all https-traffic to go through wlan0
.
Now if I use the solution suggested in the other question, https traffic will go through wlan0
, but will still have the source-address of eth1
(10.0.0.2). Since this address is not routeable for the wlan0
gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.
I figure I need to rewrite the src-addr:
# first mark it so that iproute can route it through wlan0
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.
So I thought, maybe I need to rewrite the incoming address too:
iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2
but that didn't work either. So I’m kind of stuck here. Any suggestions?
linux networking iptables routing
add a comment |
My question is basically the same as Only allow certain outbound traffic on certain interfaces.
I have two interfaces eth1
(10.0.0.2) and wlan0
(192.168.0.2).
My default route is for eth1
.
Let's say I want all https-traffic to go through wlan0
.
Now if I use the solution suggested in the other question, https traffic will go through wlan0
, but will still have the source-address of eth1
(10.0.0.2). Since this address is not routeable for the wlan0
gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.
I figure I need to rewrite the src-addr:
# first mark it so that iproute can route it through wlan0
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.
So I thought, maybe I need to rewrite the incoming address too:
iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2
but that didn't work either. So I’m kind of stuck here. Any suggestions?
linux networking iptables routing
add a comment |
My question is basically the same as Only allow certain outbound traffic on certain interfaces.
I have two interfaces eth1
(10.0.0.2) and wlan0
(192.168.0.2).
My default route is for eth1
.
Let's say I want all https-traffic to go through wlan0
.
Now if I use the solution suggested in the other question, https traffic will go through wlan0
, but will still have the source-address of eth1
(10.0.0.2). Since this address is not routeable for the wlan0
gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.
I figure I need to rewrite the src-addr:
# first mark it so that iproute can route it through wlan0
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.
So I thought, maybe I need to rewrite the incoming address too:
iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2
but that didn't work either. So I’m kind of stuck here. Any suggestions?
linux networking iptables routing
My question is basically the same as Only allow certain outbound traffic on certain interfaces.
I have two interfaces eth1
(10.0.0.2) and wlan0
(192.168.0.2).
My default route is for eth1
.
Let's say I want all https-traffic to go through wlan0
.
Now if I use the solution suggested in the other question, https traffic will go through wlan0
, but will still have the source-address of eth1
(10.0.0.2). Since this address is not routeable for the wlan0
gateway, answers won't ever come back. The easy way would be to just set the bind-addr properly in the application, but in this case it is not applicable.
I figure I need to rewrite the src-addr:
# first mark it so that iproute can route it through wlan0
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Now tcpdump sees the outgoing packets just fine and ingoing packets arrive for 192.168.0.2, however they probably never end up in the application, because all I ever get to see, is that the application is resending the SYN-packet, although the SYN-ACK was already received.
So I thought, maybe I need to rewrite the incoming address too:
iptables -A PREROUTING -t nat -i wlan0 -p tcp --sport 443 -j DNAT --to 10.0.0.2
but that didn't work either. So I’m kind of stuck here. Any suggestions?
linux networking iptables routing
linux networking iptables routing
edited Apr 13 '17 at 12:36
Community♦
1
1
asked Sep 20 '11 at 11:05
rumpelrumpel
220126
220126
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
You're close.
The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:
sudo sysctl net.ipv4.conf.wlan0.rp_filter=0
But I wouldn't recommend it. The more proper way is to create an alternate routing instance.
- The mark is necessary. Keep it.
- Source NAT is also necessary.
- The final DNAT is unnecessary, so you can remove it.
Make sure you have the iproute
package installed. If you have the ip
command then you're set (which it looks like you do, but if not get that first).
Edit /etc/iproute2/rt_tables
and add a new table by appending the following line:
200 wlan-route
You then need to configure your new routing table named wlan-route
with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
ip rule add fwmark 0x1 table wlan-route
Your final annotated script would look like this:
# Populate secondary routing table
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
# Anything with this fwmark will use the secondary routing table
ip rule add fwmark 0x1 table wlan-route
# Mark these packets so that iproute can route it through wlan-route
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add asrc
option to theip route
commands to specify the correct source address.
– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: thePOSTROUTING
SNAT
will take care of that.
– bahamat
Sep 23 '11 at 21:06
|
show 4 more comments
bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
echo 1 > /proc/sys/net/ipv4/route/flush
(see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
add a comment |
One suggestion: you should always use --sport
instead of --dport
in output chain.
NATs change the dport
and that will make your rule unuasble.
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
add a comment |
I think below is needed:
ip ru add from 192.168.0.2 table 3 prio 300
ip ro add table 3 default via 192.168.0.1 dev wlan0
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f21093%2foutput-traffic-on-different-interfaces-based-on-destination-port%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
You're close.
The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:
sudo sysctl net.ipv4.conf.wlan0.rp_filter=0
But I wouldn't recommend it. The more proper way is to create an alternate routing instance.
- The mark is necessary. Keep it.
- Source NAT is also necessary.
- The final DNAT is unnecessary, so you can remove it.
Make sure you have the iproute
package installed. If you have the ip
command then you're set (which it looks like you do, but if not get that first).
Edit /etc/iproute2/rt_tables
and add a new table by appending the following line:
200 wlan-route
You then need to configure your new routing table named wlan-route
with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
ip rule add fwmark 0x1 table wlan-route
Your final annotated script would look like this:
# Populate secondary routing table
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
# Anything with this fwmark will use the secondary routing table
ip rule add fwmark 0x1 table wlan-route
# Mark these packets so that iproute can route it through wlan-route
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add asrc
option to theip route
commands to specify the correct source address.
– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: thePOSTROUTING
SNAT
will take care of that.
– bahamat
Sep 23 '11 at 21:06
|
show 4 more comments
You're close.
The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:
sudo sysctl net.ipv4.conf.wlan0.rp_filter=0
But I wouldn't recommend it. The more proper way is to create an alternate routing instance.
- The mark is necessary. Keep it.
- Source NAT is also necessary.
- The final DNAT is unnecessary, so you can remove it.
Make sure you have the iproute
package installed. If you have the ip
command then you're set (which it looks like you do, but if not get that first).
Edit /etc/iproute2/rt_tables
and add a new table by appending the following line:
200 wlan-route
You then need to configure your new routing table named wlan-route
with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
ip rule add fwmark 0x1 table wlan-route
Your final annotated script would look like this:
# Populate secondary routing table
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
# Anything with this fwmark will use the secondary routing table
ip rule add fwmark 0x1 table wlan-route
# Mark these packets so that iproute can route it through wlan-route
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add asrc
option to theip route
commands to specify the correct source address.
– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: thePOSTROUTING
SNAT
will take care of that.
– bahamat
Sep 23 '11 at 21:06
|
show 4 more comments
You're close.
The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:
sudo sysctl net.ipv4.conf.wlan0.rp_filter=0
But I wouldn't recommend it. The more proper way is to create an alternate routing instance.
- The mark is necessary. Keep it.
- Source NAT is also necessary.
- The final DNAT is unnecessary, so you can remove it.
Make sure you have the iproute
package installed. If you have the ip
command then you're set (which it looks like you do, but if not get that first).
Edit /etc/iproute2/rt_tables
and add a new table by appending the following line:
200 wlan-route
You then need to configure your new routing table named wlan-route
with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
ip rule add fwmark 0x1 table wlan-route
Your final annotated script would look like this:
# Populate secondary routing table
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
# Anything with this fwmark will use the secondary routing table
ip rule add fwmark 0x1 table wlan-route
# Mark these packets so that iproute can route it through wlan-route
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
You're close.
The actual reason that the application isn't seeing the return traffic is because of the kernel's built in IP spoofing protection. I.e., the return traffic doesn't match the routing table and is therefore dropped. You can fix this by turning off spoofing protection like this:
sudo sysctl net.ipv4.conf.wlan0.rp_filter=0
But I wouldn't recommend it. The more proper way is to create an alternate routing instance.
- The mark is necessary. Keep it.
- Source NAT is also necessary.
- The final DNAT is unnecessary, so you can remove it.
Make sure you have the iproute
package installed. If you have the ip
command then you're set (which it looks like you do, but if not get that first).
Edit /etc/iproute2/rt_tables
and add a new table by appending the following line:
200 wlan-route
You then need to configure your new routing table named wlan-route
with a default gateway and create rules to conditionally send traffic to that table. I'll assume your default gateway is 192.168.0.1. Naturally this needs to match your actual network, and not just my assumptions.
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
ip rule add fwmark 0x1 table wlan-route
Your final annotated script would look like this:
# Populate secondary routing table
ip route add default via 192.168.0.1 dev wlan0 table wlan-route
# Anything with this fwmark will use the secondary routing table
ip rule add fwmark 0x1 table wlan-route
# Mark these packets so that iproute can route it through wlan-route
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# now rewrite the src-addr
iptables -A POSTROUTING -t nat -o wlan0 -p tcp --dport 443 -j SNAT --to 192.168.0.2
edited Sep 21 '11 at 11:27
rumpel
220126
220126
answered Sep 20 '11 at 15:35
bahamatbahamat
24.5k15090
24.5k15090
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add asrc
option to theip route
commands to specify the correct source address.
– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: thePOSTROUTING
SNAT
will take care of that.
– bahamat
Sep 23 '11 at 21:06
|
show 4 more comments
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add asrc
option to theip route
commands to specify the correct source address.
– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: thePOSTROUTING
SNAT
will take care of that.
– bahamat
Sep 23 '11 at 21:06
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Thanks for taking the time to look into this. However, this is already what I was using, (as described in the other question) so i have the additional route set up, but it's still the same. The SYN-ACKs get back to 192.168.0.2 but apparently never reach the application.
– rumpel
Sep 20 '11 at 18:06
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
Go back and read my answer again. I addressed that.
– bahamat
Sep 20 '11 at 19:14
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
The part about the spoofing protection? No change even after trying. Sorry, read it back&forth a couple of times, but didn't yet get what I am missing.
– rumpel
Sep 20 '11 at 19:23
You need to add a
src
option to the ip route
commands to specify the correct source address.– David Schwartz
Sep 23 '11 at 10:51
You need to add a
src
option to the ip route
commands to specify the correct source address.– David Schwartz
Sep 23 '11 at 10:51
@DavidSchwartz: the
POSTROUTING
SNAT
will take care of that.– bahamat
Sep 23 '11 at 21:06
@DavidSchwartz: the
POSTROUTING
SNAT
will take care of that.– bahamat
Sep 23 '11 at 21:06
|
show 4 more comments
bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
echo 1 > /proc/sys/net/ipv4/route/flush
(see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
add a comment |
bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
echo 1 > /proc/sys/net/ipv4/route/flush
(see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
add a comment |
bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
echo 1 > /proc/sys/net/ipv4/route/flush
(see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)
bahamat's solution is correct; however, please note that the only way for me to make this work was to disable the rp_filter for every interface in the system, not only the two (eth1 and wlan0 in this case) involved in the NATing.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
echo 1 > /proc/sys/net/ipv4/route/flush
(see the IMPORTANT note at the end of this page: Advanced Routing Howto -- the link posted there doesn't exist anymore, but I found it through the wayback machine)
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Feb 22 '12 at 15:42
Davide CDavide C
7111
7111
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
add a comment |
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
Thanks for this answers, I too could only get bahamats solution working considering your answer.
– Dynalon
May 13 '14 at 8:05
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
for me on a fairly standard ubuntu 12.04 LTS box, additionally to disabling rp_filter and flushing route cache I also had to strip out the interface name from iptables arguments. did not have enough time to investigate why.
– Costin Gușă
Jun 23 '14 at 15:28
add a comment |
One suggestion: you should always use --sport
instead of --dport
in output chain.
NATs change the dport
and that will make your rule unuasble.
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
add a comment |
One suggestion: you should always use --sport
instead of --dport
in output chain.
NATs change the dport
and that will make your rule unuasble.
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
add a comment |
One suggestion: you should always use --sport
instead of --dport
in output chain.
NATs change the dport
and that will make your rule unuasble.
One suggestion: you should always use --sport
instead of --dport
in output chain.
NATs change the dport
and that will make your rule unuasble.
edited Jun 24 '14 at 11:25
Networker
6,014103969
6,014103969
answered Jun 24 '14 at 9:33
user73451user73451
1
1
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
add a comment |
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
2
2
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
Is there something I'm not getting? The dport, as in destination port, can't change. It's the port of the service the session is trying to reach, e.g. http, ssh, smtp. Either you got sport and dport confused, or I'm missing something obvious. :P
– Someone
Feb 7 '16 at 18:41
add a comment |
I think below is needed:
ip ru add from 192.168.0.2 table 3 prio 300
ip ro add table 3 default via 192.168.0.1 dev wlan0
add a comment |
I think below is needed:
ip ru add from 192.168.0.2 table 3 prio 300
ip ro add table 3 default via 192.168.0.1 dev wlan0
add a comment |
I think below is needed:
ip ru add from 192.168.0.2 table 3 prio 300
ip ro add table 3 default via 192.168.0.1 dev wlan0
I think below is needed:
ip ru add from 192.168.0.2 table 3 prio 300
ip ro add table 3 default via 192.168.0.1 dev wlan0
edited Jul 24 '16 at 8:15
techraf
4,203102141
4,203102141
answered Jul 24 '16 at 6:57
user181234user181234
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f21093%2foutput-traffic-on-different-interfaces-based-on-destination-port%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown