Modify

Opened 3 years ago

Closed 3 years ago

#19050 closed defect (fixed)

Packages masquerading don't work correctly

Reported by: big.smile@… Owned by: nbd
Priority: high Milestone: Barrier Breaker 14.07
Component: kernel Version: Barrier Breaker 14.07
Keywords: masquerade, NAT, Firewall Cc:

Description

I use OpenWRT 14.07 x86 on a PC Engines APU.
This router is using between my local network and the network of my Internet provider.

Problem:
Some outgoing packages, only a few, are not masquerading: They keep their local source IP address (192.168.1.XXX) instead of getting my Wan IP address. But, they still get the mac address of my Wan interface as source mac address.

Consequence:
When this arrive, the network of my Internet provider block my connection because source IP and source mac address didn't corresponding.

If I look at IPTables, masquerade is enabled:

# iptables -L -t nat
…
Chain zone_wan_postrouting (1 references)
target     prot opt source               destination         
postrouting_wan_rule  all  --  anywhere             anywhere             /* user chain for postrouting */
MASQUERADE  all  --  anywhere             anywhere

If I listen Wan connection with "tcpdump ip -i 4 -ne -vv 'src host not XXX.XXX.XXX.XXX and ether src host aa:aa:aa:aa:aa:aa'", I've got this:

03:44:00.095703 aa:aa:aa:aa:aa:aa >ff:ff:ff:FF:FF:FF, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 30929, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.237.57912 > vvv.vvv.vvv.vvv.vvvv: Flags [R.], cksum 0x844f (correct), seq 2600988415, ack 2178291637, win 1040, options [nop,nop,TS val 6003192 ecr 844889508], length 0
03:44:00.120923 aa:aa:aa:aa:aa:aa > ff:ff:ff:FF:FF:FF, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 6495, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.237.61356 > zzz.zzz.zzz.zzz.zzzz: Flags [R.], cksum 0xccf8 (correct), seq 2701944257, ack 1628634018, win 1040, options [nop,nop,TS val 6003218 ecr 299991797], length 0

(Addresses are voluntary modified)

PS: Also tested with trunk x86_64 version, available here since 22-Feb-2015 01:23: https://downloads.openwrt.org/snapshots/trunk/x86_64/generic/
I've got the same result.

Attachments (2)

iptables.backup (8.9 KB) - added by anonymous 3 years ago.
Settings of my FW
iptables.2.backup (8.9 KB) - added by anonymous 3 years ago.
Settings of my FW

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by anonymous

Recently, I've trying to log these wrongs packets with iptables.

I use this rule:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j LOG  --log-prefix "--- INVALID PAKET ----:"

But, after some wrongs packets detected with tcpdump, if I look on the counter of this rule it's still at 0.

It seems like some packets are pass through iptables. :(

Note: All these wrongs packets have a non-local IP address as destination.

Changed 3 years ago by anonymous

Settings of my FW

Changed 3 years ago by anonymous

Settings of my FW

comment:2 Changed 3 years ago by anonymous

I noticed that all wrong packages have 80 or 443 as destination port.

comment:3 Changed 3 years ago by anonymous

I have seen a similar issue except 1) packets are not limited to 80 or 443 destination port (although they commonly are) 2) The devices generating the packets are always iDevices (iPhone, iPad).

comment:4 follow-ups: Changed 3 years ago by anonymous

Can you test with nf_conntrack_skip_filter disabled?

root@OpenWrt:~# cat /etc/sysctl.conf
...
net.netfilter.nf_conntrack_skip_filter=0

comment:5 in reply to: ↑ 4 Changed 3 years ago by anonymous

Replying to anonymous:

Can you test with nf_conntrack_skip_filter disabled?

root@OpenWrt:~# cat /etc/sysctl.conf
...
net.netfilter.nf_conntrack_skip_filter=0

Not the OP here.
That seems to be working (tested for a few hours with no leakage). I don't think it's expected behavior that I would have to set drop_invalid=1 and then tweak a netfilter setting for it to be actually recognized/processed.

comment:6 Changed 3 years ago by anonymous

If others can confirm that disabling nf_conntrack_skip_filter actually solves this issue, we should ask jow to take a look ...

comment:7 Changed 3 years ago by jow

  • Owner changed from developers to nbd
  • Status changed from new to assigned

comment:8 in reply to: ↑ 4 Changed 3 years ago by anonymous

Replying to anonymous:

Can you test with nf_conntrack_skip_filter disabled?

root@OpenWrt:~# cat /etc/sysctl.conf
...
net.netfilter.nf_conntrack_skip_filter=0

Someone have a complete documentation about this option?

I found nothing in netfilter.org or in google/duckduckgo.

comment:9 in reply to: ↑ 4 Changed 3 years ago by anonymous

Replying to anonymous:

Can you test with nf_conntrack_skip_filter disabled?

root@OpenWrt:~# cat /etc/sysctl.conf
...
net.netfilter.nf_conntrack_skip_filter=0

Why an option that concern rules from the filter table have an effect on rules from the nat table?

comment:10 in reply to: ↑ 4 Changed 3 years ago by big.smile@…

Replying to anonymous:

Can you test with nf_conntrack_skip_filter disabled?

root@OpenWrt:~# cat /etc/sysctl.conf
...
net.netfilter.nf_conntrack_skip_filter=0

Problem solved with this option turned to off.
Tested since 44 hours without wrong packets.
Thanks. ;)

comment:11 Changed 3 years ago by anonymous

This ticket should be closed, since r44873 removed the nf_conntrack_skip_filter option.

comment:12 Changed 3 years ago by nbd

  • Resolution set to fixed
  • Status changed from assigned to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.