capture ip packets when the gateway is not the ISP router

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.

asked Nov 20 '17 at 10:59

theuncle

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

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

If some sort of short-curcuit is happening, how can I avoid it?

asked Nov 20 '17 at 10:59

theuncle

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

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

If some sort of short-curcuit is happening, how can I avoid it?

asked Nov 20 '17 at 10:59

theuncle

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

If some sort of short-curcuit is happening, how can I avoid it?

asked Nov 20 '17 at 10:59

theuncle

asked Nov 20 '17 at 10:59

theuncle

asked Nov 20 '17 at 10:59

theuncle

asked Nov 20 '17 at 10:59

theuncle

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

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 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.

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

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Â |Â

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',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

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

Name

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
0
down vote

accepted

# 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.

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

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Â |Â

up vote
0
down vote

accepted

# 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.

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

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Â |Â

up vote
0
down vote

accepted

# 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.

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

2,43738

# 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.

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

2,43738

edited Nov 20 '17 at 21:46

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

2,43738

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

2,43738

answered Nov 20 '17 at 11:30

Ralph RÃ¶nnquist

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

@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Â |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

wiOt8daq,X0k57gs,E Ew9PyqHZ JXJT XcItphQpA

搜尋此網誌

mjhjmtu