capture ip packets when the gateway is not the ISP router
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
In my home network I have the following topology
Internet
|
wifi |
C ----------- A ---------- B
where
- A (static IP 192.168.0.254) is the router/AP given by my ISP.
- B (static IP 192.168.0.1) is a linux machine working as local DNS and DHCP server (running dnsmasq)
- C is any client connecting to the AP and configured by DHCP.
For now, the default gateway supplied by B (as DHCP server) is just A.
Then, suppose I want to capture in B all traffic coming from any client C. Here's what I did on B:
activate IP forwarding with
# sysctl net.ipv4.ip_forward=1"
supply B as gateway. Of course, B itself uses A as its own gateway
- run tcpdump on B to see what's going on
On a client C, I start any request, e.g.
$ traceroute www.google.com
Now, I expect that traffic originating from C is routed to B, then to A and finally to the internet.
What works. C is able to reach the internet
What does not work. Except for the first request, it seems that B is completely bypassed: tcpdump does not show anything; the address of B doesn't show up in the traceroute output. Still, I'm sure that reroute takes place because C is cut out from internet if I disable IP forwarding on B.
If some sort of short-curcuit is happening, how can I avoid it?
Disclaimer: I know that changing the network topology could solve the "capture all traffic" problem (e.g. by port mirroring etc.), but I really want to understand what's going on with my setup and how to fix that without changing topology.
linux networking ip
add a comment |Â
up vote
0
down vote
favorite
In my home network I have the following topology
Internet
|
wifi |
C ----------- A ---------- B
where
- A (static IP 192.168.0.254) is the router/AP given by my ISP.
- B (static IP 192.168.0.1) is a linux machine working as local DNS and DHCP server (running dnsmasq)
- C is any client connecting to the AP and configured by DHCP.
For now, the default gateway supplied by B (as DHCP server) is just A.
Then, suppose I want to capture in B all traffic coming from any client C. Here's what I did on B:
activate IP forwarding with
# sysctl net.ipv4.ip_forward=1"
supply B as gateway. Of course, B itself uses A as its own gateway
- run tcpdump on B to see what's going on
On a client C, I start any request, e.g.
$ traceroute www.google.com
Now, I expect that traffic originating from C is routed to B, then to A and finally to the internet.
What works. C is able to reach the internet
What does not work. Except for the first request, it seems that B is completely bypassed: tcpdump does not show anything; the address of B doesn't show up in the traceroute output. Still, I'm sure that reroute takes place because C is cut out from internet if I disable IP forwarding on B.
If some sort of short-curcuit is happening, how can I avoid it?
Disclaimer: I know that changing the network topology could solve the "capture all traffic" problem (e.g. by port mirroring etc.), but I really want to understand what's going on with my setup and how to fix that without changing topology.
linux networking ip
1
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A viassh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).
â dirkt
Nov 20 '17 at 11:18
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In my home network I have the following topology
Internet
|
wifi |
C ----------- A ---------- B
where
- A (static IP 192.168.0.254) is the router/AP given by my ISP.
- B (static IP 192.168.0.1) is a linux machine working as local DNS and DHCP server (running dnsmasq)
- C is any client connecting to the AP and configured by DHCP.
For now, the default gateway supplied by B (as DHCP server) is just A.
Then, suppose I want to capture in B all traffic coming from any client C. Here's what I did on B:
activate IP forwarding with
# sysctl net.ipv4.ip_forward=1"
supply B as gateway. Of course, B itself uses A as its own gateway
- run tcpdump on B to see what's going on
On a client C, I start any request, e.g.
$ traceroute www.google.com
Now, I expect that traffic originating from C is routed to B, then to A and finally to the internet.
What works. C is able to reach the internet
What does not work. Except for the first request, it seems that B is completely bypassed: tcpdump does not show anything; the address of B doesn't show up in the traceroute output. Still, I'm sure that reroute takes place because C is cut out from internet if I disable IP forwarding on B.
If some sort of short-curcuit is happening, how can I avoid it?
Disclaimer: I know that changing the network topology could solve the "capture all traffic" problem (e.g. by port mirroring etc.), but I really want to understand what's going on with my setup and how to fix that without changing topology.
linux networking ip
In my home network I have the following topology
Internet
|
wifi |
C ----------- A ---------- B
where
- A (static IP 192.168.0.254) is the router/AP given by my ISP.
- B (static IP 192.168.0.1) is a linux machine working as local DNS and DHCP server (running dnsmasq)
- C is any client connecting to the AP and configured by DHCP.
For now, the default gateway supplied by B (as DHCP server) is just A.
Then, suppose I want to capture in B all traffic coming from any client C. Here's what I did on B:
activate IP forwarding with
# sysctl net.ipv4.ip_forward=1"
supply B as gateway. Of course, B itself uses A as its own gateway
- run tcpdump on B to see what's going on
On a client C, I start any request, e.g.
$ traceroute www.google.com
Now, I expect that traffic originating from C is routed to B, then to A and finally to the internet.
What works. C is able to reach the internet
What does not work. Except for the first request, it seems that B is completely bypassed: tcpdump does not show anything; the address of B doesn't show up in the traceroute output. Still, I'm sure that reroute takes place because C is cut out from internet if I disable IP forwarding on B.
If some sort of short-curcuit is happening, how can I avoid it?
Disclaimer: I know that changing the network topology could solve the "capture all traffic" problem (e.g. by port mirroring etc.), but I really want to understand what's going on with my setup and how to fix that without changing topology.
linux networking ip
asked Nov 20 '17 at 10:59
theuncle
31
31
1
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A viassh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).
â dirkt
Nov 20 '17 at 11:18
add a comment |Â
1
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A viassh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).
â dirkt
Nov 20 '17 at 11:18
1
1
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A via
ssh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).â dirkt
Nov 20 '17 at 11:18
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A via
ssh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).â dirkt
Nov 20 '17 at 11:18
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
You need host B to do NAT translations so that A does not see the same packet again. Instead B should send out packets through A as if they originated from B. To achieve that you add an iptables
rule as follows:
# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE
By that rule, all packets out from B will be rewritten to be as if sourced from B, but keeping a table of back translations, so that associated responses can be back-translated and sent to C.
Note the -s ...
part which limits the rule to only apply to packets sourced from C (or it could be set as the local LAN), and e.g., not the response packets.
EDIT (taking @theuncle's comment into account): The explanation as to why it doesn't work without NAT would be, that host B realizes the packet comes in and goes out unaltered on the same interface, so it can improve networking by telling C to talk directly with A for the traffic concerned.
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
You need host B to do NAT translations so that A does not see the same packet again. Instead B should send out packets through A as if they originated from B. To achieve that you add an iptables
rule as follows:
# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE
By that rule, all packets out from B will be rewritten to be as if sourced from B, but keeping a table of back translations, so that associated responses can be back-translated and sent to C.
Note the -s ...
part which limits the rule to only apply to packets sourced from C (or it could be set as the local LAN), and e.g., not the response packets.
EDIT (taking @theuncle's comment into account): The explanation as to why it doesn't work without NAT would be, that host B realizes the packet comes in and goes out unaltered on the same interface, so it can improve networking by telling C to talk directly with A for the traffic concerned.
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
add a comment |Â
up vote
0
down vote
accepted
You need host B to do NAT translations so that A does not see the same packet again. Instead B should send out packets through A as if they originated from B. To achieve that you add an iptables
rule as follows:
# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE
By that rule, all packets out from B will be rewritten to be as if sourced from B, but keeping a table of back translations, so that associated responses can be back-translated and sent to C.
Note the -s ...
part which limits the rule to only apply to packets sourced from C (or it could be set as the local LAN), and e.g., not the response packets.
EDIT (taking @theuncle's comment into account): The explanation as to why it doesn't work without NAT would be, that host B realizes the packet comes in and goes out unaltered on the same interface, so it can improve networking by telling C to talk directly with A for the traffic concerned.
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
You need host B to do NAT translations so that A does not see the same packet again. Instead B should send out packets through A as if they originated from B. To achieve that you add an iptables
rule as follows:
# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE
By that rule, all packets out from B will be rewritten to be as if sourced from B, but keeping a table of back translations, so that associated responses can be back-translated and sent to C.
Note the -s ...
part which limits the rule to only apply to packets sourced from C (or it could be set as the local LAN), and e.g., not the response packets.
EDIT (taking @theuncle's comment into account): The explanation as to why it doesn't work without NAT would be, that host B realizes the packet comes in and goes out unaltered on the same interface, so it can improve networking by telling C to talk directly with A for the traffic concerned.
You need host B to do NAT translations so that A does not see the same packet again. Instead B should send out packets through A as if they originated from B. To achieve that you add an iptables
rule as follows:
# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE
By that rule, all packets out from B will be rewritten to be as if sourced from B, but keeping a table of back translations, so that associated responses can be back-translated and sent to C.
Note the -s ...
part which limits the rule to only apply to packets sourced from C (or it could be set as the local LAN), and e.g., not the response packets.
EDIT (taking @theuncle's comment into account): The explanation as to why it doesn't work without NAT would be, that host B realizes the packet comes in and goes out unaltered on the same interface, so it can improve networking by telling C to talk directly with A for the traffic concerned.
edited Nov 20 '17 at 21:46
answered Nov 20 '17 at 11:30
Ralph Rönnquist
2,43738
2,43738
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
add a comment |Â
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1) This is not the problem, the problem is that packets from A never reach B. So you can set up NAT on B until you are blue in the face, if there are no packets from A to NAT on B, it won't help. 2) If you control A, you don't need B to do NAT. If you don't control A, you won't be able to fix it.
â dirkt
Nov 20 '17 at 12:49
1
1
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
@ralph Thanks, this is helpful and solves my problem. Meantime, I also discovered that my setup, even without the iptables rule you gave, half-works until machine B sends an ICMP Redirect Host message to C.
â theuncle
Nov 20 '17 at 18:03
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%2f405744%2fcapture-ip-packets-when-the-gateway-is-not-the-isp-router%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
1
Assuming you wanted to say "C uses B as gateway, while B uses A as gateway", then this will only work if A bridges WLAN and LAN, because otherwise C and B are not in the same segment. So you need to get into the A via
ssh
or otherwise, and look and possible change what A does. If A just forwards packets from C to the internet, there's nothing you can do unless you can change the way A works (e.g. by flashing it with OpenWRT).â dirkt
Nov 20 '17 at 11:18