Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1607
  • Last Modified:

tcpdump affecting iptables in linux

I am trying to nat packets originating from within my network going to my external ip to a specific machine back within the same network

The reason for this, is software is setup to connect to the external address outside the network and I wish to speed it up by connecting locally within the network without changing the IP (and internal DNS isn't an option)

The strange thing is, if I monitor the connection with tcpdump, it all works. As soon as I turn off tcpdump, it stops working, the packets seem to never get SNAT'd
eg: tcpdump -i br0 host and tcp port 81

Thinking tcpdump turns on promiscuous mode, i have tried turning on promisc mode on the internal network card, however that didn't help.

I have also monitored everything I could in /proc/sys/net/ to see if tcpdump modifies any of the files, however, I can't see any changes.

I have also cleared out every other rule in iptables to specifically test this one.

br0 is a bridge of my ethernet cards, with my external ip renamed to <extip>
iptables config:

Chain PREROUTING (policy ACCEPT 6256 packets, 817K bytes)
 pkts bytes target     prot opt in     out     source               destination        
 2020  121K DNAT       tcp  --  br0    *            <extip>      tcp dpt:6060 to:

Chain INPUT (policy ACCEPT 5054 packets, 633K bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 1296 packets, 95746 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain POSTROUTING (policy ACCEPT 1337 packets, 101K bytes)
 pkts bytes target     prot opt in     out     source               destination        
  252 15552 SNAT       tcp  --  *      *              tcp dpt:81 to:
  • 4
  • 3
  • 3
  • +1
4 Solutions
Some questions:
- could you provide us with information (or a graph) of the network interfaces on this linux machine
- is this machine the default gateway for the internal network
- did you restart iptables after turning off tcpdump
- what are your iptables FORWARD chain rules
DFPITCAuthor Commented:
it has a ppp0 and br0(eth0,eth1,eth2)
yes, it is the default gateway
not sure what you mean by "restart iptables", iptables doesn't need restarting, it is in the kernel.
there are no forward rules (I assume you mean on the filter table) and the default policy is ACCEPT
> not sure what you mean by "restart iptables"

I mean flush the iptables and reinsert the rules. In some distributions you can do this with "service iptables restart". On the other hand you could restart the entire system.

> there are no forward rules

Is this your firewall and you have no rules?

You could add "-j LOG" rules to see where the packet stops (or if it does not reach PREROUTING chain). But for the start you could zero out the counters ("iptables -Z") and see if they are incremented when you try to make a connection.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Duncan RoeSoftware DeveloperCommented:
I find it fascinating that by running tcpdump you can change the behaviour of the network. That is not supposed to happen.
One thing I have noticed with tcpdump is that it will display incoming packets that iptables drops.
On which system were you running tcpdump? ( / / other (please specify))
Which system has the rules you posted? ( / / other (please specify))
Your 2 rules appear to me to be a little asymmetric - I would have thought the POSTROUTING rule would map to
nociSoftware EngineerCommented:
This is double nat...

External packets get first DNAT'ed to the internal server, and later they get SNATéd to the internal IP address of the router...
(Then you don't need to add routes to the nat gateway. If all protocols can handle this is a BIG if.... that depends on the protocol at hand.
And based on data the br0 interface has as interface. is the intended server.
This setup is generaly usable when the system doing NAT is NOT the gateway for this kind of traffic. But is should be avoided otherwise if possible.

so packets from x.x.x.x:???? -> ext-ip:6060 become: ->
Iptables will take care of the return track.  The POSTROUTING you refer to is for firewall that need to nat all traffic from a local net to the internet at large.

Also promiscuous mode has to do with receipt of packets (a network adapter will filter on MAC address[few can be defined], unless Promiscuous mode is effective, then all packets get transferred to the driver).

Did you also test with getting a bunch of transfers acros and start tcpdump after that?
DFPITCAuthor Commented:
I have restarted the system with no luck, i've also cleared all iptables and routes and started from scratch.
I do have firewall rules, however, to simplify the problem I have cleared them all to test this.
for this test, I have no forward rules, however, the default policy is accept

I agree it is strange that tcpdump can change the network's behavior. This is why I came here :)
I am running tcpdump on the same machine (the gateway:
The two rules need to exist together for it to work, eg: DNAT forwards the source machine packets to the destination machine, however, if there was no SNAT rule, because the source machine is on the same network as the destination machine, the destination machine would reply to the source machine directly, not the gateway. The source machine expects packets back from the gateway, so it would ignore the packets directly from the destination machine. the SNAT rule changes the packet source to be the gateway so the destination machine replies to it, and the gateway replies back to the source machine.
Hope this makes sense.

These rules are to forward internal packets only,

Just to clarify again what's going on:
There is software that runs on a mobile or laptop, it connects to is the gateway machine using internally

External Access: (note I have disabled these rules for this test and have not included this in the example)
If the mobile or laptop is on the internet (outside the network) it connects to
A rule is set to DNAT this to the internal server
This works properly as the source address for the packets will be set to an internet address and the default gateway for is, so the packets get back to the gateway and back to the mobile / laptop.

Internal Access: (this is where the problem happens)
If the mobile or laptop is inside the network it still connects to (I can't change this)
Rather that it going out to the internet and back again (very slow) I want to simply tell the gateway to redirect all requests that are coming from inside the network (on interface br0) to the internal server on port 81 (
As stated before, in order to do this, i need two rules, a DNAT rule and an SNAT rule.

The problem is, this works fine, only while tcpdump is running

nociSoftware EngineerCommented:
The SNAT is not needed if the default route on points to
The SNAT only serves as a poormans routing fix.
You try to use U-turn routing, which is not quite a common practice.
It might help if the SNAT rule only matches source packets instead of ALL packets.
iptstate might be of help here: in analysing the iptables architecture.

I see 2 solutions here:
Use the routing normaly Add an.interface to the gateway, hang the internal network on that (so the machine is NOT on the local network anymore)

Use a proxy (f.e. squid ) that relays the request.

If you want non-intrusive tcpdumps, create a copy/monitor port through a managed switch or use a HUB (NOT a SWITCH) between the port & swtich
and monitor the traffic way.
Duncan RoeSoftware DeveloperCommented:
The question remains, why ever should tcpdump intrude?
As for the SNAT rule, do things work without it and with tcpdump running? I didn't think conntrack took care of SNAT. I would still be interested to know if also SNATting the port as I suggested before works any better.
DFPITCAuthor Commented:
ok.. I finally found the answer...
ifconfig br0 promisc

because promiscuous mode was off for the bridge, the network card on the gateway never received packets not destined for itself, because it was on the same network with a different IP, the gateway ignored the packets.. damn that was hard to diagnose.


@noci: I can't explain it any more than I did in my previous post.. normally, you wouldn't need to DNAT/SNAT within your own network, however, in this case I do.

@duncan_roe: As I suspected, the only thing that tcpdump is turn promiscuous mode on, which ended up being the case.
nociSoftware EngineerCommented:
The problem is why do you need promiscuous mode on the bridge.

How many interfaces are on the bridge.
If it is one it definitely should be working...
I assume more than one:
then are those interfaces all connected to ONE switch (or ONE switch stack) and are those interface configured as a channel (name depending on supplier).

If the switch is an unmanaged switch you are in trouble because the interface will flip traffic and data might end up on the wrong interface. In that case promiscuous mode repairs the direct problem.
A managed switch without configuring the channels will show flapping in the logs.
But it doesn't solve the trouble in your switch which might show itself as a rather slow interface...

If only one interface in the bridge is use i presume the need for promiscuous mode probably vanishes.

DFPITCAuthor Commented:
Ok, even though I solved this myself, I'm awarding some points cas I want to thank you for the effort :)

> because promiscuous mode was off for the bridge, the network card on the gateway
> never received packets not destined for itself, because it was on the same network
> with a different IP, the gateway ignored the packets.. damn that was hard to diagnose.

Just for my curiosity - could you elaborate a bit on this. Where were the packets destined if not the gateway machine?
For us to undesrstand the setup it is very helpfull to see a network diagram of the machine - all interfaces, all IPs, where the internet is connected, where the not working machine is connected, where the source (test) machine is connected etc.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now