Kim Pedersen
2005-Aug-10 09:36 UTC
Problem with DNAT causing martian source messages in log files
I have a system with 4 interfaces
2 Internal networks, and 2 internet links.
I am running Shorewall 2.4.2, and Linux Mandrake kernel 2.6.12, with
iptables version 1.3.3
I am providing services (mainly SMTP) on both internet links, and sending
outbound traffic on the eth2 interface using Masq.
Incoming SMTP connections get DNATed to server on 192.168.1.10
Incoming connections to port 25 arriving the ADSL interface (Default GW)
gets DNATed and forwarded correctly to 172.150.1.10, however incoming SMTP
connections arriving on eth0 / the T1 interface gets dropped with:
Aug 11 17:08:40 fw kernel: martian source 172.150.1.10 from 52.22.142.146,
on dev eth0
Aug 11 17:08:40 fw kernel: ll header:
00:0e:0c:00:64:56:00:02:7e:23:c3:0c:08:00
I have used tcpdump, and see the incoming Syn packet, but nothing leaves
the firewall on any interface.
What it seems like to me, is that the packet arrives on eth0, gets
rewritten in the Prerouting chain, and then the kernel labels it as a
martian. Now I have probably been staring at logfiles for too long, because
it
strikes me a bit weird now that the log entry above says martian *source*
172.150.1.10, as DNAT should be rewriting the *destination* and not the
source IP.
Is there something blatantly obvious that I have overseen, or might there
be a bug/feature in Shorewall that I havent''heard about yet?
Overview of the interfaces on the router/firewall
eth0 / 10.1.90.190/26 with gateway 10.1.1.1 (T1)
The gateway (T1) maps public IP address 200.50.91.190 to my firewall on
10.1.90.190, which is dealt with by having an interface alias "eth0:0"
eth1 / 172.150.1.1/24 (Internal network #1)
eth2 / 10.0.0.1/24 with gateway 10.0.0.2 (ADSL)
ADSL uses bridging to map public IP 200.50.87.247 on to the firewall,
which is dealt with by having an interface alias "eth1:0"
eth3 / 172.150.2.1 (Internal network #2)
Thanks,
Kim
shorewall status output:
-------------------------
Counters reset Thu Aug 11 16:36:10 AST 2005
Chain AllowICMPs (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3 code 4
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 11
Chain Drop (1 references)
pkts bytes target prot opt in out source
destination
14580 1393K RejectAuth all -- * * 0.0.0.0/0
0.0.0.0/0
14580 1393K dropBcast all -- * * 0.0.0.0/0
0.0.0.0/0
1412 79398 AllowICMPs icmp -- * * 0.0.0.0/0
0.0.0.0/0
1622 98323 dropInvalid all -- * * 0.0.0.0/0
0.0.0.0/0
211 18957 DropSMB all -- * * 0.0.0.0/0
0.0.0.0/0
120 14289 DropUPnP all -- * * 0.0.0.0/0
0.0.0.0/0
11 1980 dropNotSyn tcp -- * * 0.0.0.0/0
0.0.0.0/0
119 12789 DropDNSrep all -- * * 0.0.0.0/0
0.0.0.0/0
Chain DropDNSrep (2 references)
pkts bytes target prot opt in out source
destination
1 428 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:53
Chain DropSMB (1 references)
pkts bytes target prot opt in out source
destination
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:135
10 780 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:445
28 1344 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:135
2 96 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:139
51 2448 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:445
Chain DropUPnP (2 references)
pkts bytes target prot opt in out source
destination
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:1900
Chain INPUT (policy DROP 8 packets, 926 bytes)
pkts bytes target prot opt in out source
destination
56 2800 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
13107 1313K eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
362 105K eth1_in all -- eth1 * 0.0.0.0/0
0.0.0.0/0
1736 109K eth2_in all -- eth2 * 0.0.0.0/0
0.0.0.0/0
5482 406K eth3_in all -- eth3 * 0.0.0.0/0
0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:INPUT:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy DROP 19 packets, 905 bytes)
pkts bytes target prot opt in out source
destination
834 43394 eth0_fwd all -- eth0 * 0.0.0.0/0
0.0.0.0/0
58438 3878K eth1_fwd all -- eth1 * 0.0.0.0/0
0.0.0.0/0
29218 18M eth2_fwd all -- eth2 * 0.0.0.0/0
0.0.0.0/0
6269 434K eth3_fwd all -- eth3 * 0.0.0.0/0
0.0.0.0/0
834 43394 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
833 43316 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:FORWARD:REJECT:'' queue_threshold 1
833 43316 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
56 2800 ACCEPT all -- * lo 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * eth0 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
0 0 ACCEPT udp -- * eth1 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
0 0 ACCEPT udp -- * eth2 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
0 0 ACCEPT udp -- * eth3 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
79 6556 fw2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
324 22555 fw2net all -- * eth2 0.0.0.0/0
0.0.0.0/0
5651 1939K fw2wlan all -- * eth3 0.0.0.0/0
0.0.0.0/0
35 3562 fw2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:OUTPUT:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain Reject (4 references)
pkts bytes target prot opt in out source
destination
834 43394 RejectAuth all -- * * 0.0.0.0/0
0.0.0.0/0
834 43394 dropBcast all -- * * 0.0.0.0/0
0.0.0.0/0
833 43316 AllowICMPs icmp -- * * 0.0.0.0/0
0.0.0.0/0
834 43394 dropInvalid all -- * * 0.0.0.0/0
0.0.0.0/0
834 43394 RejectSMB all -- * * 0.0.0.0/0
0.0.0.0/0
833 43316 DropUPnP all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 dropNotSyn tcp -- * * 0.0.0.0/0
0.0.0.0/0
833 43316 DropDNSrep all -- * * 0.0.0.0/0
0.0.0.0/0
Chain RejectAuth (2 references)
pkts bytes target prot opt in out source
destination
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:113
Chain RejectSMB (1 references)
pkts bytes target prot opt in out source
destination
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:135
1 78 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:445
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:135
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:139
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:445
Chain all2all (0 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:all2all:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain dropBcast (2 references)
pkts bytes target prot opt in out source
destination
12958 1295K DROP all -- * * 0.0.0.0/0
0.0.0.0/0 PKTTYPE = broadcast
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 PKTTYPE = multicast
Chain dropInvalid (2 references)
pkts bytes target prot opt in out source
destination
1411 79366 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
Chain dropNotSyn (2 references)
pkts bytes target prot opt in out source
destination
1 1500 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:!0x17/0x02
Chain dynamic (8 references)
pkts bytes target prot opt in out source
destination
Chain eth0_fwd (1 references)
pkts bytes target prot opt in out source
destination
834 43394 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 ACCEPT all -- * eth2 0.0.0.0/0
0.0.0.0/0
0 0 net2all all -- * eth3 0.0.0.0/0
0.0.0.0/0
0 0 net2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
Chain eth0_in (1 references)
pkts bytes target prot opt in out source
destination
13101 1313K dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
20 6964 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
13087 1306K net2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain eth1_fwd (1 references)
pkts bytes target prot opt in out source
destination
35990 1929K dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 loc2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
52912 3398K loc2net all -- * eth2 0.0.0.0/0
0.0.0.0/0
5526 480K loc2wlan all -- * eth3 0.0.0.0/0
0.0.0.0/0
Chain eth1_in (1 references)
pkts bytes target prot opt in out source
destination
346 102K dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
6 1968 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
356 103K loc2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source
destination
2 120 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 ACCEPT all -- * eth0 0.0.0.0/0
0.0.0.0/0
921 1232K net2all all -- * eth3 0.0.0.0/0
0.0.0.0/0
28297 17M net2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
Chain eth2_in (1 references)
pkts bytes target prot opt in out source
destination
1535 90558 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
1736 109K net2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain eth3_fwd (1 references)
pkts bytes target prot opt in out source
destination
2075 200K dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 wlan2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
768 53389 wlan2net all -- * eth2 0.0.0.0/0
0.0.0.0/0
5501 381K wlan2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
Chain eth3_in (1 references)
pkts bytes target prot opt in out source
destination
20 2784 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
5482 406K wlan2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2loc (1 references)
pkts bytes target prot opt in out source
destination
34 3491 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
1 71 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2net (2 references)
pkts bytes target prot opt in out source
destination
390 28235 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
13 876 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2wlan (1 references)
pkts bytes target prot opt in out source
destination
5651 1939K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain loc2fw (1 references)
pkts bytes target prot opt in out source
destination
16 2766 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
340 100K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain loc2net (2 references)
pkts bytes target prot opt in out source
destination
16922 1470K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
35990 1929K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain loc2wlan (1 references)
pkts bytes target prot opt in out source
destination
5526 480K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2all (4 references)
pkts bytes target prot opt in out source
destination
921 1232K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
14580 1393K Drop all -- * * 0.0.0.0/0
0.0.0.0/0
118 12361 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:net2all:DROP:'' queue_threshold 1
118 12361 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2fw (2 references)
pkts bytes target prot opt in out source
destination
207 18823 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
36 3108 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 8
14580 1393K net2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2loc (2 references)
pkts bytes target prot opt in out source
destination
28295 17M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0
172.150.1.10 tcp dpt:993
0 0 ACCEPT tcp -- * * 0.0.0.0/0
172.150.1.10 tcp dpt:995
2 120 ACCEPT tcp -- * * 0.0.0.0/0
172.150.1.10 tcp dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0
172.150.1.10 tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0
172.150.1.10 tcp dpt:443
0 0 net2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain reject (11 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 PKTTYPE = broadcast
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 PKTTYPE = multicast
0 0 DROP all -- * * 10.1.255.255
0.0.0.0/0
0 0 DROP all -- * * 200.50.91.190
0.0.0.0/0
0 0 DROP all -- * * 172.150.1.255
0.0.0.0/0
0 0 DROP all -- * * 10.0.0.255
0.0.0.0/0
0 0 DROP all -- * * 200.50.87.247
0.0.0.0/0
0 0 DROP all -- * * 172.150.2.255
0.0.0.0/0
0 0 DROP all -- * * 255.255.255.255
0.0.0.0/0
0 0 DROP all -- * * 224.0.0.0/4
0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with tcp-reset
1 78 REJECT udp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
833 43316 REJECT icmp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-unreachable
0 0 REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
Chain shorewall (0 references)
pkts bytes target prot opt in out source
destination
Chain smurfs (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG all -- * * 10.1.255.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 10.1.255.255
0.0.0.0/0
0 0 LOG all -- * * 200.50.91.190
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 200.50.91.190
0.0.0.0/0
0 0 LOG all -- * * 172.150.1.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 172.150.1.255
0.0.0.0/0
0 0 LOG all -- * * 10.0.0.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 10.0.0.255
0.0.0.0/0
0 0 LOG all -- * * 200.50.87.247
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 200.50.87.247
0.0.0.0/0
0 0 LOG all -- * * 172.150.2.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 172.150.2.255
0.0.0.0/0
0 0 LOG all -- * * 255.255.255.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 255.255.255.255
0.0.0.0/0
0 0 LOG all -- * * 224.0.0.0/4
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 224.0.0.0/4
0.0.0.0/0
Chain wlan2fw (1 references)
pkts bytes target prot opt in out source
destination
5462 403K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
20 2784 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain wlan2loc (1 references)
pkts bytes target prot opt in out source
destination
3582 188K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
1919 193K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain wlan2net (2 references)
pkts bytes target prot opt in out source
destination
612 46141 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
156 7248 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Jan 4 18:51:19 fw ifplugd(eth2)[30718]: client: ERROR: Command
"/sbin/iptables -A smurfs -s 10.1.255.255 -j LOG --log-level info
--log-prefix "Shorewall:smurfs:DROP:"" Failed
NAT Table
Chain PREROUTING (policy ACCEPT 123K packets, 10M bytes)
pkts bytes target prot opt in out source
destination
10728 1036K net_dnat all -- eth0 * 0.0.0.0/0
0.0.0.0/0
126 11312 net_dnat all -- eth2 * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 7324 packets, 554K bytes)
pkts bytes target prot opt in out source
destination
6 456 eth0_masq all -- * eth0 0.0.0.0/0
0.0.0.0/0
3236 186K eth2_masq all -- * eth2 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 1083 packets, 101K bytes)
pkts bytes target prot opt in out source
destination
Chain eth0_masq (1 references)
pkts bytes target prot opt in out source
destination
0 0 masq1 all -- * * 172.150.1.0/24
0.0.0.0/0
0 0 MASQUERADE all -- * * 172.150.2.0/24
0.0.0.0/0
Chain eth2_masq (1 references)
pkts bytes target prot opt in out source
destination
3179 183K masq2 all -- * * 172.150.1.0/24
0.0.0.0/0
52 2496 MASQUERADE all -- * * 172.150.2.0/24
0.0.0.0/0
Chain masq1 (1 references)
pkts bytes target prot opt in out source
destination
0 0 RETURN all -- * * 172.150.1.49
0.0.0.0/0
0 0 MASQUERADE all -- * * 0.0.0.0/0
0.0.0.0/0
Chain masq2 (1 references)
pkts bytes target prot opt in out source
destination
48 2304 RETURN all -- * * 172.150.1.49
0.0.0.0/0
3131 181K MASQUERADE all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net_dnat (2 references)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:993 to:172.150.1.10
0 0 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:995 to:172.150.1.10
153 7572 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:25 to:172.150.1.10
0 0 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 to:172.150.1.10
0 0 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:443 to:172.150.1.10
Mangle Table
Chain PREROUTING (policy ACCEPT 752K packets, 205M bytes)
pkts bytes target prot opt in out source
destination
54299 20M CONNMARK all -- * * 0.0.0.0/0
0.0.0.0/0 CONNMARK match !0x0 CONNMARK restore
3405 207K routemark all -- eth2 * 0.0.0.0/0
0.0.0.0/0 MARK match 0x0
10742 1037K routemark all -- eth0 * 0.0.0.0/0
0.0.0.0/0 MARK match 0x0
116K 24M pretos all -- * * 0.0.0.0/0
0.0.0.0/0
116K 24M tcpre all -- * * 0.0.0.0/0
0.0.0.0/0
Chain INPUT (policy ACCEPT 478K packets, 51M bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 949K packets, 271M bytes)
pkts bytes target prot opt in out source
destination
94933 23M routefwd all -- * * 0.0.0.0/0
0.0.0.0/0
94806 23M tcfor all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 52980 packets, 13M bytes)
pkts bytes target prot opt in out source
destination
6463 2028K routeout all -- * * 0.0.0.0/0
0.0.0.0/0
6379 2018K outtos all -- * * 0.0.0.0/0
0.0.0.0/0
6377 2017K tcout all -- * * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 1003K packets, 285M bytes)
pkts bytes target prot opt in out source
destination
100K 24M tcpost all -- * * 0.0.0.0/0
0.0.0.0/0
Chain outtos (1 references)
pkts bytes target prot opt in out source
destination
302 21374 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
5678 1966K TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:20 TOS set 0x08
Chain pretos (1 references)
pkts bytes target prot opt in out source
destination
5475 404K TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
186 17374 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
26 1374 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:21 TOS set 0x10
28 1874 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
11 1814 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
9 516 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:20 TOS set 0x08
Chain routefwd (1 references)
pkts bytes target prot opt in out source
destination
Chain routemark (2 references)
pkts bytes target prot opt in out source
destination
3405 207K MARK all -- eth2 * 0.0.0.0/0
0.0.0.0/0 MARK set 0x1
10742 1037K MARK all -- eth0 * 0.0.0.0/0
0.0.0.0/0 MARK set 0x2
14147 1244K CONNMARK all -- * * 0.0.0.0/0
0.0.0.0/0 MARK match !0x0 CONNMARK save mask 0xff
Chain routeout (1 references)
pkts bytes target prot opt in out source
destination
Chain tcfor (1 references)
pkts bytes target prot opt in out source
destination
Chain tcout (1 references)
pkts bytes target prot opt in out source
destination
Chain tcpost (1 references)
pkts bytes target prot opt in out source
destination
Chain tcpre (1 references)
pkts bytes target prot opt in out source
destination
52714 20M RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 CONNMARK match 0x1
14208 1377K RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 CONNMARK match 0x2
tcp 6 427174 ESTABLISHED src=172.150.1.53 dst=68.255.72.48 sport=1621
dport=6346 packets=746 bytes=51655 src=68.255.72.48 dst=10.1.90.190
sport=6346 dport=1621 packets=776 bytes=95006 [ASSURED] mark=0 use=1
tcp 6 426755 ESTABLISHED src=172.150.1.53 dst=84.100.230.60 sport=1671
dport=6346 packets=324 bytes=29692 src=84.100.230.60 dst=10.1.90.190
sport=6346 dport=1671 packets=288 bytes=35837 [ASSURED] mark=0 use=1
udp 17 86 src=172.150.1.53 dst=66.90.162.72 sport=26346 dport=13430
packets=8 bytes=313 src=66.90.162.72 dst=10.0.0.1 sport=13430 dport=26346
packets=3 bytes=147 [ASSURED] mark=1 use=1
tcp 6 431988 ESTABLISHED src=172.150.1.53 dst=201.26.198.235
sport=2768 dport=11596 packets=74 bytes=22115 src=201.26.198.235
dst=10.0.0.1 sport=11596 dport=2768 packets=54 bytes=6047 [ASSURED] mark=1
use=1
udp 17 29 src=172.150.1.10 dst=192.35.51.30 sport=32933 dport=53
packets=1 bytes=64 src=192.35.51.30 dst=10.0.0.1 sport=53 dport=32933
packets=1 bytes=134 mark=1 use=1
tcp 6 431999 ESTABLISHED src=172.150.2.152 dst=192.168.4.205
sport=2302 dport=1319 packets=602 bytes=31814 src=192.168.4.205
dst=172.150.2.152 sport=1319 dport=2302 packets=608 bytes=42207 [ASSURED]
mark=0 use=1
tcp 6 427295 ESTABLISHED src=172.150.1.53 dst=172.188.44.220
sport=1576 dport=6346 packets=681 bytes=58105 src=172.188.44.220
dst=10.1.90.190 sport=6346 dport=1576 packets=660 bytes=120121 [ASSURED]
mark=0 use=1
udp 17 23 src=10.1.50.186 dst=10.1.255.255 sport=1338 dport=3000
packets=2530 bytes=485760 [UNREPLIED] src=10.1.255.255 dst=10.1.50.186
sport=3000 dport=1338 packets=0 bytes=0 mark=2 use=1
udp 17 74 src=172.150.1.53 dst=83.97.161.74 sport=26346 dport=6346
packets=12 bytes=799 src=83.97.161.74 dst=10.0.0.1 sport=6346 dport=26346
packets=5 bytes=251 [ASSURED] mark=1 use=1
udp 17 10 src=172.150.2.49 dst=172.150.1.10 sport=123 dport=123
packets=1 bytes=76 src=172.150.1.10 dst=172.150.2.49 sport=123 dport=123
packets=1 bytes=76 mark=0 use=1
tcp 6 92 SYN_SENT src=172.150.1.49 dst=69.50.167.242 sport=1380
dport=80 packets=3 bytes=144 [UNREPLIED] src=69.50.167.242 dst=172.150.1.49
sport=80 dport=1380 packets=0 bytes=0 mark=0 use=1
tcp 6 413480 ESTABLISHED src=172.150.2.242 dst=172.150.1.59 sport=3059
dport=80 packets=59 bytes=2460 src=172.150.1.59 dst=172.150.2.242 sport=80
dport=3059 packets=58 bytes=4255 [ASSURED] mark=0 use=1
tcp 6 416893 ESTABLISHED src=172.150.1.53 dst=69.230.210.210
sport=4841 dport=6346 packets=431 bytes=35007 src=69.230.210.210
dst=10.1.90.190 sport=6346 dport=4841 packets=438 bytes=53242 [ASSURED]
mark=2 use=1
tcp 6 11 TIME_WAIT src=172.150.1.51 dst=207.68.171.245 sport=1070
dport=80 packets=17 bytes=970 src=207.68.171.245 dst=10.0.0.1 sport=80
dport=1070 packets=25 bytes=33755 [ASSURED] mark=1 use=1
udp 17 151 src=172.150.1.53 dst=84.98.219.17 sport=26346 dport=15537
packets=6 bytes=362 src=84.98.219.17 dst=10.0.0.1 sport=15537 dport=26346
packets=6 bytes=487 [ASSURED] mark=1 use=1
udp 17 23 src=172.150.2.46 dst=172.150.1.10 sport=123 dport=123
packets=1 bytes=76 src=172.150.1.10 dst=172.150.2.46 sport=123 dport=123
packets=1 bytes=76 mark=0 use=1
IP Configuration
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:0c:00:64:56 brd ff:ff:ff:ff:ff:ff
inet 10.1.90.190/16 brd 10.1.255.255 scope global eth0
inet 200.50.91.190/32 brd 200.50.91.190 scope global eth0:0
inet6 fe80::20e:cff:fe00:6456/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:0c:00:64:fc brd ff:ff:ff:ff:ff:ff
inet 172.150.1.1/24 brd 172.150.1.255 scope global eth1
inet6 fe80::20e:cff:fe00:64fc/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:30:48:53:d6:84 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
inet 200.50.87.247/30 brd 200.50.87.247 scope global eth2:0
inet6 fe80::230:48ff:fe53:d684/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:53:d6:85 brd ff:ff:ff:ff:ff:ff
inet 172.150.2.1/24 brd 172.150.2.255 scope global eth3
inet6 fe80::230:48ff:fe53:d685/64 scope link
valid_lft forever preferred_lft forever
6: sit0: <NOARP,UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 brd 0.0.0.0
inet6 ::172.150.2.1/96 scope global
valid_lft forever preferred_lft forever
inet6 ::10.0.0.1/96 scope global
valid_lft forever preferred_lft forever
inet6 ::172.150.1.1/96 scope global
valid_lft forever preferred_lft forever
inet6 ::200.50.91.190/96 scope global
valid_lft forever preferred_lft forever
inet6 ::10.1.90.190/96 scope global
valid_lft forever preferred_lft forever
inet6 ::127.0.0.1/96 scope host
valid_lft forever preferred_lft forever
IP Stats
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
258078 3529 0 0 0 0
TX: bytes packets errors dropped carrier collsns
258078 3529 0 0 0 0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:0c:00:64:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
233179126 1408160 0 0 0 0
TX: bytes packets errors dropped carrier collsns
16918152 174900 0 0 0 88
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:0c:00:64:fc brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
58311503 530670 0 0 0 0
TX: bytes packets errors dropped carrier collsns
221952972 452016 0 0 0 0
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:30:48:53:d6:84 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
22620595 38439 0 0 0 0
TX: bytes packets errors dropped carrier collsns
5493015 64159 0 0 0 0
5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:53:d6:85 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
1440593 15773 0 0 0 0
TX: bytes packets errors dropped carrier collsns
4567374 16498 0 0 0 0
6: sit0: <NOARP,UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 brd 0.0.0.0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
/proc
/proc/sys/net/ipv4/ip_forward = 1
/proc/sys/net/ipv4/icmp_echo_ignore_all = 0
/proc/sys/net/ipv4/conf/all/proxy_arp = 0
/proc/sys/net/ipv4/conf/all/arp_filter = 0
/proc/sys/net/ipv4/conf/all/rp_filter = 1
/proc/sys/net/ipv4/conf/all/log_martians = 1
/proc/sys/net/ipv4/conf/default/proxy_arp = 0
/proc/sys/net/ipv4/conf/default/arp_filter = 0
/proc/sys/net/ipv4/conf/default/rp_filter = 1
/proc/sys/net/ipv4/conf/default/log_martians = 1
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth0/arp_filter = 0
/proc/sys/net/ipv4/conf/eth0/rp_filter = 1
/proc/sys/net/ipv4/conf/eth0/log_martians = 0
/proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth1/arp_filter = 0
/proc/sys/net/ipv4/conf/eth1/rp_filter = 1
/proc/sys/net/ipv4/conf/eth1/log_martians = 0
/proc/sys/net/ipv4/conf/eth2/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth2/arp_filter = 0
/proc/sys/net/ipv4/conf/eth2/rp_filter = 1
/proc/sys/net/ipv4/conf/eth2/log_martians = 0
/proc/sys/net/ipv4/conf/eth3/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth3/arp_filter = 0
/proc/sys/net/ipv4/conf/eth3/rp_filter = 1
/proc/sys/net/ipv4/conf/eth3/log_martians = 0
/proc/sys/net/ipv4/conf/lo/proxy_arp = 0
/proc/sys/net/ipv4/conf/lo/arp_filter = 0
/proc/sys/net/ipv4/conf/lo/rp_filter = 1
/proc/sys/net/ipv4/conf/lo/log_martians = 0
Routing Rules
0: from all lookup local
32713: from 200.50.91.190 lookup SL
32714: from 10.1.90.190 lookup SL
32715: from all fwmark 0x2 lookup SL
32716: from 200.50.87.247 lookup CWADSL
32717: from 10.0.0.1 lookup CWADSL
32718: from all fwmark 0x1 lookup CWADSL
32766: from all lookup main
32767: from all lookup default
Table CWADSL:
10.0.0.2 dev eth2 scope link
200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247
192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1
172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric
10
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10
default via 10.0.0.2 dev eth2
Table default:
Table local:
local 172.150.2.1 dev eth3 proto kernel scope host src 172.150.2.1
broadcast 172.150.2.0 dev eth3 proto kernel scope link src 172.150.2.1
broadcast 172.150.1.255 dev eth1 proto kernel scope link src 172.150.1.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 10.0.0.1 dev eth2 proto kernel scope host src 10.0.0.1
broadcast 10.0.0.0 dev eth2 proto kernel scope link src 10.0.0.1
local 200.50.91.190 dev eth0 proto kernel scope host src 200.50.91.190
broadcast 200.50.91.190 dev eth0 proto kernel scope link src
200.50.91.190
broadcast 10.1.0.0 dev eth0 proto kernel scope link src 10.1.90.190
local 172.150.1.1 dev eth1 proto kernel scope host src 172.150.1.1
broadcast 172.150.2.255 dev eth3 proto kernel scope link src 172.150.2.1
broadcast 172.150.1.0 dev eth1 proto kernel scope link src 172.150.1.1
broadcast 10.1.255.255 dev eth0 proto kernel scope link src 10.1.90.190
local 10.1.90.190 dev eth0 proto kernel scope host src 10.1.90.190
local 200.50.87.247 dev eth2 proto kernel scope host src 200.50.87.247
broadcast 200.50.87.247 dev eth2 proto kernel scope link src
200.50.87.247
broadcast 10.0.0.255 dev eth2 proto kernel scope link src 10.0.0.1
broadcast 200.50.87.244 dev eth2 proto kernel scope link src
200.50.87.247
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Table main:
200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247
192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10
172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric
10
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10
default via 10.0.0.2 dev eth2
Table SL:
10.1.1.1 dev eth0 scope link
200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247
192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1
172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric
10
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10
default via 10.1.1.1 dev eth0
ARP
? (172.150.2.45) at 00:0E:38:68:9B:AD [ether] on eth3
? (10.1.1.3) at 00:30:7B:92:B3:24 [ether] on eth0
? (172.150.2.36) at 00:0D:BC:8A:B2:CF [ether] on eth3
? (10.1.1.1) at 00:02:7E:23:C3:0C [ether] on eth0
? (172.150.1.59) at 00:E0:DB:04:37:E4 [ether] on eth1
? (172.150.2.3) at 00:90:7A:01:47:74 [ether] on eth3
? (172.150.2.2) at 00:90:7A:01:47:5E [ether] on eth3
? (172.150.2.44) at 00:0D:BC:8A:B0:CE [ether] on eth3
? (10.1.40.75) at 00:12:79:D9:2C:4B [ether] on eth0
? (172.150.1.53) at 00:07:E9:4D:4A:41 [ether] on eth1
? (172.150.1.10) at 00:30:48:53:B9:FC [ether] on eth1
? (172.150.1.12) at 00:D0:CF:02:F5:0B [ether] on eth1
? (172.150.2.47) at 00:0D:BC:C3:5C:F4 [ether] on eth3
? (172.150.2.35) at 00:0D:BC:8A:B2:DC [ether] on eth3
? (172.150.2.42) at 00:0D:BC:5C:16:D4 [ether] on eth3
? (10.0.0.2) at 00:06:4F:10:DC:27 [ether] on eth2
? (172.150.2.49) at 00:0D:BC:78:7D:77 [ether] on eth3
? (172.150.1.51) at 00:80:AD:87:C2:67 [ether] on eth1
Modules
ipt_TOS 2112 12
ipt_MASQUERADE 2720 4
ipt_ULOG 6532 5
ipt_REJECT 5888 4
ipt_LOG 6528 8
ipt_mark 1472 3
ipt_state 1600 22
ipt_pkttype 1472 4
ipt_CONNMARK 1984 2
ipt_MARK 2240 2
ipt_connmark 1504 3
ipt_owner 3232 0
ipt_recent 9580 0
ipt_iprange 1664 0
ipt_physdev 2096 0
ipt_multiport 2368 0
ipt_conntrack 2208 0
ip_nat_irc 1792 0
ip_nat_tftp 1504 0
ip_nat_ftp 2496 0
ip_conntrack_irc 70608 1 ip_nat_irc
ip_conntrack_tftp 3280 1 ip_nat_tftp
ip_conntrack_ftp 71568 1 ip_nat_ftp
ip_conntrack 38280 10
ipt_MASQUERADE,ipt_state,ipt_conntrack,ip_nat_irc,ip_nat_tftp,ip_nat_ftp,iptable_nat,ip_conntrack_irc,ip_conntrack_tftp,ip_conntrack_ftp
ip_tables 19520 20
ipt_TOS,ipt_MASQUERADE,ipt_ULOG,ipt_REJECT,ipt_LOG,ipt_mark,ipt_state,ipt_pkttype,ipt_CONNMARK,ipt_MARK,ipt_connmark,ipt_owner,ipt_recent,ipt_iprange,ipt_physdev,ipt_multiport,ipt_conntrack,iptable_mangle,iptable_nat,iptable_filter
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-10 09:58 UTC
Re: Problem with DNAT causing martian source messages in log files
Another update: If I change the default gateway set in /etc/sysconfig/network to be 10.0.0.2 (ADSL modem), the problematic interface gets switched. In other words it is now incoming requests on eth2 that generates the martian source errors. I made the assumption that using the providers config file in shorewall would take care of the issue with routing traffic out the same interface it comes in on, and if this is not a shorewall related problem I apologise for dumping it on the list. Kim --On Wednesday, August 10, 2005 05:36 -0400 Kim Pedersen <kim@cncsltd.com> wrote:> > I have a system with 4 interfaces > > 2 Internal networks, and 2 internet links. > > I am running Shorewall 2.4.2, and Linux Mandrake kernel 2.6.12, with > iptables version 1.3.3 > > I am providing services (mainly SMTP) on both internet links, and sending > outbound traffic on the eth2 interface using Masq. > > Incoming SMTP connections get DNATed to server on 192.168.1.10 > > Incoming connections to port 25 arriving the ADSL interface (Default GW) > gets DNATed and forwarded correctly to 172.150.1.10, however incoming > SMTP connections arriving on eth0 / the T1 interface gets dropped with: > > Aug 11 17:08:40 fw kernel: martian source 172.150.1.10 from > 52.22.142.146, on dev eth0 > Aug 11 17:08:40 fw kernel: ll header: > 00:0e:0c:00:64:56:00:02:7e:23:c3:0c:08:00 > > I have used tcpdump, and see the incoming Syn packet, but nothing leaves > the firewall on any interface. > > What it seems like to me, is that the packet arrives on eth0, gets > rewritten in the Prerouting chain, and then the kernel labels it as a > martian. Now I have probably been staring at logfiles for too long, > because it > strikes me a bit weird now that the log entry above says martian > *source* 172.150.1.10, as DNAT should be rewriting the *destination* and > not the source IP. > > > Is there something blatantly obvious that I have overseen, or might there > be a bug/feature in Shorewall that I havent''heard about yet? > > > > Overview of the interfaces on the router/firewall > > eth0 / 10.1.90.190/26 with gateway 10.1.1.1 (T1) > The gateway (T1) maps public IP address 200.50.91.190 to my firewall on > 10.1.90.190, which is dealt with by having an interface alias "eth0:0" > > eth1 / 172.150.1.1/24 (Internal network #1) > > eth2 / 10.0.0.1/24 with gateway 10.0.0.2 (ADSL) > ADSL uses bridging to map public IP 200.50.87.247 on to the firewall, > which is dealt with by having an interface alias "eth1:0" > > eth3 / 172.150.2.1 (Internal network #2) > > > Thanks, > Kim------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-10 10:00 UTC
Re: Problem with DNAT causing martian source messages in log files
Here it is: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY CWADSL 1 1 main eth2 10.0.0.2 track SL 2 2 main eth0 10.1.1.1 track #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE Kim --On Thursday, August 11, 2005 16:49 -0500 Jerry Vonau <jvonau@shaw.ca> wrote:>> Table main: >> >> 200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247 >> 192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10 >> 172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1 >> 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 >> 172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 >> metric 10 >> 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric >> 10 default via 10.0.0.2 dev eth2 >> >> Table SL: >> >> 10.1.1.1 dev eth0 scope link >> 200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247 >> 192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10 >> 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 >> 172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1 >> 172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 >> metric 10 >> 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric >> 10 default via 10.1.1.1 dev eth0 > > Can you post your providers file, please. > > Jerry > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-10 10:15 UTC
Re: Problem with DNAT causing martian source messages in log files
>> What it seems like to me, is that the packet arrives on eth0, gets >> rewritten in the Prerouting chain, and then the kernel labels it as a >> martian. Now I have probably been staring at logfiles for too long, >> because it >> strikes me a bit weird now that the log entry above says martian >> *source* 172.150.1.10, as DNAT should be rewriting the *destination* and >> not the source IP. >> >> >> Is there something blatantly obvious that I have overseen, or might >> there be a bug/feature in Shorewall that I havent''heard about yet? > > This usually signals the presence of a physical cabling problem which has > resulted in two of your firewall interfaces being on the same LAN. > Unfortunately, your Shorewall logging configuration is incorrect so that > no Shorewall log messages are showing up in the "shorewall status".Hi Tom, Thanks for the input. Unfortunately that is not the problem. eth0 exits the firewall/network card and goes straight into a mediaconverter and is sent to a network a couple of miles away, while the other 3 eth connections are being sent to 2 separate switches and the ADSL modem (for eth2). Those switches are not linked in any way other than the firewall (And being on the same electrical circuit :). If I had internal traffic frolicking about on eth0 I would have the IT department from my upstream link on my back. :-/ I have gotten my ulogd service running in the meantime though, in case. -- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Jerry Vonau
2005-Aug-11 21:49 UTC
Re: Problem with DNAT causing martian source messages in log files
> > I have a system with 4 interfaces > > 2 Internal networks, and 2 internet links. > > I am running Shorewall 2.4.2, and Linux Mandrake kernel 2.6.12, with > iptables version 1.3.3 > > I am providing services (mainly SMTP) on both internet links, and sending > outbound traffic on the eth2 interface using Masq. > > Incoming SMTP connections get DNATed to server on 192.168.1.10 > > Incoming connections to port 25 arriving the ADSL interface (Default GW) > gets DNATed and forwarded correctly to 172.150.1.10, however incoming SMTP > connections arriving on eth0 / the T1 interface gets dropped with: > > Aug 11 17:08:40 fw kernel: martian source 172.150.1.10 from 52.22.142.146, > on dev eth0 > Aug 11 17:08:40 fw kernel: ll header: > 00:0e:0c:00:64:56:00:02:7e:23:c3:0c:08:00 > > I have used tcpdump, and see the incoming Syn packet, but nothing leaves > the firewall on any interface. > > What it seems like to me, is that the packet arrives on eth0, gets > rewritten in the Prerouting chain, and then the kernel labels it as a > martian. Now I have probably been staring at logfiles for too long, because > it > strikes me a bit weird now that the log entry above says martian *source* > 172.150.1.10, as DNAT should be rewriting the *destination* and not the > source IP. > > > Is there something blatantly obvious that I have overseen, or might there > be a bug/feature in Shorewall that I havent''heard about yet? > > > > Overview of the interfaces on the router/firewall > > eth0 / 10.1.90.190/26 with gateway 10.1.1.1 (T1) > The gateway (T1) maps public IP address 200.50.91.190 to my firewall on > 10.1.90.190, which is dealt with by having an interface alias "eth0:0" > > eth1 / 172.150.1.1/24 (Internal network #1) > > eth2 / 10.0.0.1/24 with gateway 10.0.0.2 (ADSL) > ADSL uses bridging to map public IP 200.50.87.247 on to the firewall, > which is dealt with by having an interface alias "eth1:0" > > eth3 / 172.150.2.1 (Internal network #2) > > > Thanks, > Kim ><snip>> > Routing Rules > > 0: from all lookup local > 32713: from 200.50.91.190 lookup SL > 32714: from 10.1.90.190 lookup SL > 32715: from all fwmark 0x2 lookup SL > 32716: from 200.50.87.247 lookup CWADSL > 32717: from 10.0.0.1 lookup CWADSL > 32718: from all fwmark 0x1 lookup CWADSL > 32766: from all lookup main > 32767: from all lookup default > > Table CWADSL: > > 10.0.0.2 dev eth2 scope link > 200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247 > 192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10 > 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 > 172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1 > 172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric > 10 > 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10 > default via 10.0.0.2 dev eth2 > > Table default: > > > Table local: > > local 172.150.2.1 dev eth3 proto kernel scope host src 172.150.2.1 > broadcast 172.150.2.0 dev eth3 proto kernel scope link src 172.150.2.1 > broadcast 172.150.1.255 dev eth1 proto kernel scope link src 172.150.1.1 > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > local 10.0.0.1 dev eth2 proto kernel scope host src 10.0.0.1 > broadcast 10.0.0.0 dev eth2 proto kernel scope link src 10.0.0.1 > local 200.50.91.190 dev eth0 proto kernel scope host src 200.50.91.190 > broadcast 200.50.91.190 dev eth0 proto kernel scope link src > 200.50.91.190 > broadcast 10.1.0.0 dev eth0 proto kernel scope link src 10.1.90.190 > local 172.150.1.1 dev eth1 proto kernel scope host src 172.150.1.1 > broadcast 172.150.2.255 dev eth3 proto kernel scope link src 172.150.2.1 > broadcast 172.150.1.0 dev eth1 proto kernel scope link src 172.150.1.1 > broadcast 10.1.255.255 dev eth0 proto kernel scope link src 10.1.90.190 > local 10.1.90.190 dev eth0 proto kernel scope host src 10.1.90.190 > local 200.50.87.247 dev eth2 proto kernel scope host src 200.50.87.247 > broadcast 200.50.87.247 dev eth2 proto kernel scope link src > 200.50.87.247 > broadcast 10.0.0.255 dev eth2 proto kernel scope link src 10.0.0.1 > broadcast 200.50.87.244 dev eth2 proto kernel scope link src > 200.50.87.247 > broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > > Table main: > > 200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247 > 192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10 > 172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1 > 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 > 172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric > 10 > 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10 > default via 10.0.0.2 dev eth2 > > Table SL: > > 10.1.1.1 dev eth0 scope link > 200.50.87.244/30 dev eth2 proto kernel scope link src 200.50.87.247 > 192.168.4.0/24 via 172.150.1.12 dev eth1 metric 10 > 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 > 172.150.2.0/24 dev eth3 proto kernel scope link src 172.150.2.1 > 172.150.1.0/24 dev eth1 proto kernel scope link src 172.150.1.1 metric > 10 > 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.90.190 metric 10 > default via 10.1.1.1 dev eth0Can you post your providers file, please. Jerry ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-11 21:56 UTC
Re: Problem with DNAT causing martian source messages in log files
Kim Pedersen wrote:> > I have a system with 4 interfaces > > 2 Internal networks, and 2 internet links. > > I am running Shorewall 2.4.2, and Linux Mandrake kernel 2.6.12, with > iptables version 1.3.3 > > I am providing services (mainly SMTP) on both internet links, and > sending outbound traffic on the eth2 interface using Masq. > > Incoming SMTP connections get DNATed to server on 192.168.1.10 > > Incoming connections to port 25 arriving the ADSL interface (Default GW) > gets DNATed and forwarded correctly to 172.150.1.10, however incoming > SMTP connections arriving on eth0 / the T1 interface gets dropped with: > > Aug 11 17:08:40 fw kernel: martian source 172.150.1.10 from > 52.22.142.146, on dev eth0 > Aug 11 17:08:40 fw kernel: ll header: > 00:0e:0c:00:64:56:00:02:7e:23:c3:0c:08:00 > > I have used tcpdump, and see the incoming Syn packet, but nothing leaves > the firewall on any interface. > > What it seems like to me, is that the packet arrives on eth0, gets > rewritten in the Prerouting chain, and then the kernel labels it as a > martian. Now I have probably been staring at logfiles for too long, > because it > strikes me a bit weird now that the log entry above says martian > *source* 172.150.1.10, as DNAT should be rewriting the *destination* and > not the source IP. > > > Is there something blatantly obvious that I have overseen, or might > there be a bug/feature in Shorewall that I havent''heard about yet?This usually signals the presence of a physical cabling problem which has resulted in two of your firewall interfaces being on the same LAN. Unfortunately, your Shorewall logging configuration is incorrect so that no Shorewall log messages are showing up in the "shorewall status". -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Jerry Vonau
2005-Aug-11 22:19 UTC
Re: Problem with DNAT causing martian source messages in log files
> > Here it is: > > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY > OPTIONS COPY > CWADSL 1 1 main eth2 10.0.0.2 track > SL 2 2 main eth0 10.1.1.1 track > #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > >You overlooked a feature the "COPY" column: CWADSL 1 1 main eth2 10.0.0.2 track eth1,eth3 SL 2 2 main eth0 10.1.1.1 track eth1,eth3 This will remove "all other providers" from a provider''s routing table, and just add what is listed in copy. Jerry ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-11 22:37 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Jerry Thanks for that! I was using 2.4.0, and updated to 2.4.2 when I ran into problems, and didn''t look into the COPY feature (As it seemed performance related) Thanks again Kim --On Thursday, August 11, 2005 17:19 -0500 Jerry Vonau <jvonau@shaw.ca> wrote:> >> >> Here it is: >> >> # NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY >> OPTIONS COPY >> CWADSL 1 1 main eth2 10.0.0.2 >> track SL 2 2 main eth0 10.1.1.1 >> track >> # LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE >> >> > > You overlooked a feature the "COPY" column: > > CWADSL 1 1 main eth2 10.0.0.2 > track eth1,eth3 SL 2 2 main eth0 > 10.1.1.1 track eth1,eth3 > > This will remove "all other providers" from a provider''s routing table, > and just add what is listed in copy. > > Jerry > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-11 22:51 UTC
Re: Problem with DNAT causing martian source messages in log files
Kim Pedersen wrote:> I was using 2.4.0, and updated to 2.4.2 when I ran into problems, and > didn''t look into the COPY feature (As it seemed performance related) > >Kim, Just so we''re clear -- did that correct your problem? Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Kim Pedersen
2005-Aug-11 22:52 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Tom, I ran shorewall for a few minutes with LOGALLNEW=debug I''ve included the log section here (A search backwards and forwards +/- 30 seconds shows only a bunch of peer to peer traffic entries on port 6346) Aug 11 18:26:53 fw kernel: Shorewall:mangle:PREROUTING:IN=eth2 OUT= MAC=00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 SRC=72.22.132.1 46 DST=200.50.87.247 LEN=60 TOS=0x10 PREC=0x00 TTL=62 ID=60229 DF PROTO=TCP SPT=50209 DPT=25 WINDOW=2144 RES=0x00 SYN URGP=0 Aug 11 18:26:53 fw kernel: Shorewall:nat:PREROUTING:IN=eth2 OUT= MAC=00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 SRC=72.22.132.146 DST=200.50.87.247 LEN=60 TOS=0x10 PREC=0x00 TTL=62 ID=60229 DF PROTO=TCP SPT=50209 DPT=25 WINDOW=2144 RES=0x00 SYN URGP=0 Aug 11 18:26:53 fw kernel: martian source 172.150.1.10 from 72.22.132.146, on dev eth2 Aug 11 18:26:53 fw kernel: ll header: 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00>> Is there something blatantly obvious that I have overseen, or might >> there be a bug/feature in Shorewall that I havent''heard about yet? > > This usually signals the presence of a physical cabling problem which has > resulted in two of your firewall interfaces being on the same LAN. > Unfortunately, your Shorewall logging configuration is incorrect so that > no Shorewall log messages are showing up in the "shorewall status". > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key-- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-11 22:54 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Tom, No, unfortunately not. I just sent off the syslog/debug entries in my previous email to see if that helps shed any light on the problem. Kim --On Thursday, August 11, 2005 15:51 -0700 Tom Eastep <teastep@shorewall.net> wrote:> Kim Pedersen wrote: > >> I was using 2.4.0, and updated to 2.4.2 when I ran into problems, and >> didn''t look into the COPY feature (As it seemed performance related) >> >> > > Kim, > > Just so we''re clear -- did that correct your problem? > > Thanks, > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key-- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-11 23:01 UTC
Re: Problem with DNAT causing martian source messages in log files
Kim Pedersen wrote:> > Hi Tom, > > No, unfortunately not. > > I just sent off the syslog/debug entries in my previous email to see if > that helps shed any light on the problem. >Then we need another "shorewall status" to see your current routing configuration (hint: A martian is a packet that has a source address with no route through the interface that the packet came in on). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Kim Pedersen
2005-Aug-11 23:21 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Tom, --On Thursday, August 11, 2005 16:01 -0700 Tom Eastep <teastep@shorewall.net> wrote:> Then we need another "shorewall status" to see your current routing > configuration (hint: A martian is a packet that has a source address with > no route through the interface that the packet came in on).OK, I''ve attached the new shorewall status output in previous email (Pending moderation due to size) I know about the martian packet, and that is what I find a bit confusing, as it is a DNAT rule that is triggering the martian log entry.>From "rules"---- # Allow encrypted Pop3 and IMAP DNAT net loc:172.150.1.10 tcp 993 DNAT net loc:172.150.1.10 tcp 995 # Allow incoming mail and SSH connections DNAT net loc:172.150.1.10 tcp smtp DNAT net loc:172.150.1.10 tcp ssh ---->From "/var/log/syslog"---- Aug 11 18:43:15 fw kernel: martian source 172.150.1.10 from 72.22.132.146, on dev eth2 Aug 11 18:43:15 fw kernel: ll header: 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 Aug 11 18:43:18 fw kernel: martian source 172.150.1.10 from 72.22.132.146, on dev eth2 Aug 11 18:43:18 fw kernel: ll header: 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 Aug 11 18:43:24 fw kernel: martian source 172.150.1.10 from 72.22.132.146, on dev eth2 Aug 11 18:43:24 fw kernel: ll header: 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 ---- A packet comes in on 200.50.87.247/eth2 on destination port 25/tcp. It should be rewritten/DNATed to dst ip 172.150.1.10, but instead what appears to be happening is that it gets its source address rewritten to 172.150.1.10, and hence triggers the martian alert. Kim -- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-11 23:42 UTC
Re: Problem with DNAT causing martian source messages in log files
Kim Pedersen wrote:> > Hi Tom, > > --On Thursday, August 11, 2005 16:01 -0700 Tom Eastep > <teastep@shorewall.net> wrote: > >> Then we need another "shorewall status" to see your current routing >> configuration (hint: A martian is a packet that has a source address with >> no route through the interface that the packet came in on). > > > OK, I''ve attached the new shorewall status output in previous email > (Pending moderation due to size) > > I know about the martian packet, and that is what I find a bit > confusing, as it is a DNAT rule that is triggering the martian log entry. > > >> From "rules" > > ---- > # Allow encrypted Pop3 and IMAP > DNAT net loc:172.150.1.10 tcp 993 > DNAT net loc:172.150.1.10 tcp 995 > > # Allow incoming mail and SSH connections > DNAT net loc:172.150.1.10 tcp smtp > DNAT net loc:172.150.1.10 tcp ssh > ---- > >> From "/var/log/syslog" > > ---- > Aug 11 18:43:15 fw kernel: martian source 172.150.1.10 from > 72.22.132.146, on dev eth2 > Aug 11 18:43:15 fw kernel: ll header: > 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 > Aug 11 18:43:18 fw kernel: martian source 172.150.1.10 from > 72.22.132.146, on dev eth2 > Aug 11 18:43:18 fw kernel: ll header: > 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 > Aug 11 18:43:24 fw kernel: martian source 172.150.1.10 from > 72.22.132.146, on dev eth2 > Aug 11 18:43:24 fw kernel: ll header: > 00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 > ---- > > A packet comes in on 200.50.87.247/eth2 on destination port 25/tcp. It > should be rewritten/DNATed to dst ip 172.150.1.10, but instead what > appears to be happening is that it gets its source address rewritten to > 172.150.1.10, and hence triggers the martian alert.No -- the system is complaining about the 200.50.87.247, not 172.150.1.10!!! The wording of that messages is very confusing. What SHOULD happen is that the packet comes in on eth2, gets marked with the provider mark for that interface and has the source IP verified against the routing table for that source. By the time we get to routing, the destination IP has already been rewritten by the DNAT rule so we see 172.150.1.10. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep
2005-Aug-11 23:53 UTC
Re: Problem with DNAT causing martian source messages in log files
>From your original post:> 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 > link/ether 00:30:48:53:d6:84 brd ff:ff:ff:ff:ff:ff > inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2 > inet 200.50.87.247/30 brd 200.50.87.247 scope global eth2:0------------- -------------> inet6 fe80::230:48ff:fe53:d684/64 scope link > valid_lft forever preferred_lft foreverYou have configured this interface with the IP address that corresponds to the broadcast address of its network -- I''m uncertain what sorts of problems that causes. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Kim Pedersen
2005-Aug-11 23:56 UTC
Re: Problem with DNAT causing martian source messages in log files
>> A packet comes in on 200.50.87.247/eth2 on destination port 25/tcp. It >> should be rewritten/DNATed to dst ip 172.150.1.10, but instead what >> appears to be happening is that it gets its source address rewritten to >> 172.150.1.10, and hence triggers the martian alert. > > No -- the system is complaining about the 200.50.87.247, not > 172.150.1.10!!! The wording of that messages is very confusing. What > SHOULD happen is that the packet comes in on eth2, gets marked with the > provider mark for that interface and has the source IP verified against > the routing table for that source. By the time we get to routing, the > destination IP has already been rewritten by the DNAT rule so we see > 172.150.1.10.Hmmm... that *does* seem a little backwards... :) The 200.50.87.247 exists as an alias to eth2, with the primary address being 10.0.0.1. I can ping 10.0.0.1 from the ADSL modem (10.0.0.2) Changing the DNAT for port 22 to just ACCEPTING the connection, instead of forwarding to the internal 172.150.1.10 system will make incoming connections on that interface work: ACCEPT net fw tcp ssh #DNAT net loc:172.150.1.10 tcp ssh In this case no martians are logged. I am not sure whether this is shorewall or iptables related. But I''ve been at this for a long time, so I think I better take a break, and continue tomorrow. I''ve looked over your detailed home setup, and see we are both using bridging (I would have pinned the whole problem down on being related to that, if it wasn''t because I get the same symptoms one eth0 if I switch the default gateway on the system over to be 10.1.1.1 on eth0) -- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Kim Pedersen
2005-Aug-12 00:00 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Tom,>> From your original post: > >> 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 >> link/ether 00:30:48:53:d6:84 brd ff:ff:ff:ff:ff:ff >> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2 >> inet 200.50.87.247/30 brd 200.50.87.247 scope global eth2:0 > ------------- ------------- >> inet6 fe80::230:48ff:fe53:d684/64 scope link >> valid_lft forever preferred_lft forever > > You have configured this interface with the IP address that corresponds > to the broadcast address of its network -- I''m uncertain what sorts of > problems that causes.Thanks for pointing it out. I changed the netmask at one point to see if it made any difference (Because aliases "inherits" undefined attributes from the parent interface, in this case a netmask of 255.255.0.0. I wasn''t sure it would be a good thing to have such a large block of addresses considered local, so I changed it) -- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-12 00:05 UTC
Re: Problem with DNAT causing martian source messages in log files
Tom Eastep wrote:> Kim Pedersen wrote: >>Hi Tom, >> >>--On Thursday, August 11, 2005 16:01 -0700 Tom Eastep >><teastep@shorewall.net> wrote: >> >>>Then we need another "shorewall status" to see your current routing >>>configuration (hint: A martian is a packet that has a source address with >>>no route through the interface that the packet came in on). >> >>OK, I''ve attached the new shorewall status output in previous email >>(Pending moderation due to size) >> >>I know about the martian packet, and that is what I find a bit >>confusing, as it is a DNAT rule that is triggering the martian log entry. >> >> >>>From "rules" >>---- >># Allow encrypted Pop3 and IMAP >>DNAT net loc:172.150.1.10 tcp 993 >>DNAT net loc:172.150.1.10 tcp 995 >> >># Allow incoming mail and SSH connections >>DNAT net loc:172.150.1.10 tcp smtp >>DNAT net loc:172.150.1.10 tcp ssh >>---- >> >>>From "/var/log/syslog" >>---- >>Aug 11 18:43:15 fw kernel: martian source 172.150.1.10 from >>72.22.132.146, on dev eth2 >>Aug 11 18:43:15 fw kernel: ll header: >>00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 >>Aug 11 18:43:18 fw kernel: martian source 172.150.1.10 from >>72.22.132.146, on dev eth2 >>Aug 11 18:43:18 fw kernel: ll header: >>00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 >>Aug 11 18:43:24 fw kernel: martian source 172.150.1.10 from >>72.22.132.146, on dev eth2 >>Aug 11 18:43:24 fw kernel: ll header: >>00:30:48:53:d6:84:00:06:4f:10:dc:27:08:00 >>---- >> >>A packet comes in on 200.50.87.247/eth2 on destination port 25/tcp. It >>should be rewritten/DNATed to dst ip 172.150.1.10, but instead what >>appears to be happening is that it gets its source address rewritten to >>172.150.1.10, and hence triggers the martian alert. > > No -- the system is complaining about the 200.50.87.247, not > 172.150.1.10!!!For the benefit of those who may stumble over this email thread and be totally confused, the complaint is actually about 72.22.132.146 (the source IP of the packet). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Jerry Vonau
2005-Aug-12 01:48 UTC
Re: Problem with DNAT causing martian source messages in log files
Any reason your not using balance as an option here? Your trying to reply to 2 inbound networks, give it a try. You can tilt the results toward one by using balance= , Higher number wins the preference. If that is not enough you can use tcrules to force traffic to use a provider Jerry> > Hi Jerry > > Thanks for that! > > I was using 2.4.0, and updated to 2.4.2 when I ran into problems, and > didn''t look into the COPY feature (As it seemed performance related) > > > Thanks again > > Kim > > > > --On Thursday, August 11, 2005 17:19 -0500 Jerry Vonau <jvonau@shaw.ca> > wrote: > > > > >> > >> Here it is: > >> > >> # NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY > >> OPTIONS COPY > >> CWADSL 1 1 main eth2 10.0.0.2 > >> track SL 2 2 main eth0 10.1.1.1 > >> track > >> # LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > >> > >> > > > > You overlooked a feature the "COPY" column: > > > > CWADSL 1 1 main eth2 10.0.0.2 > > track eth1,eth3 SL 2 2 main eth0 > > 10.1.1.1 track eth1,eth3 > > > > This will remove "all other providers" from a provider''s routing table, > > and just add what is listed in copy. > > > > Jerry > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices Agile & Plan-Driven Development * Managing Projects & Teams * > > Testing & QA Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > -- > Regards, > Kim Pedersen > Computer & Network Consulting Services Ltd. > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep
2005-Aug-12 16:26 UTC
Re: Problem with DNAT causing martian source messages in log files
Jerry Vonau wrote:> Any reason your not using balance as an option here? > Your trying to reply to 2 inbound networks, give it a try. > You can tilt the results toward one by using balance= , > Higher number wins the preference. If that is not enough > you can use tcrules to force traffic to use a provider >Kim, And if adding ''balance'' to the options for eth0 and eth2 corrects the problem then I''d like to get the details of which kernel you are running. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Kim Pedersen
2005-Aug-16 12:36 UTC
Re: Problem with DNAT causing martian source messages in log files
Hi Jerry, --On Thursday, 11 August, 2005 20:48 -0500 Jerry Vonau <jvonau@shaw.ca> wrote:> Any reason your not using balance as an option here? > Your trying to reply to 2 inbound networks, give it a try. > You can tilt the results toward one by using balance= , > Higher number wins the preference. If that is not enough > you can use tcrules to force traffic to use a providerI didn''t use balance because I wanted to get the issue of the martians out of the way before adding additional complexity into the fray. (I''ve done load balancing before, but wanted to use/try the new providers file in Shorewall, to have it done in a standardised way). Interestingly enough, adding the balance option made things work and the martians go away. To me it seems that the track option should be sufficient to achieve what I wanted. Ultimately I wanted to have balancing in the end anyhow, so with the balance option in, I am set. For Toms information, here is the output of uname -a: 2.6.11-12mdksmp #1 SMP / i686 Intel(R) Xeon(TM) At first I was using 2.6.11-6mdksmp, but did the minor upgrade to 2.6.11-12. I realise that there''s been quite a few changes to NAT/Netfilter in 2.6.11, so maybe the glitch comes from here? Tom, let me know if there is any other information you might be interested in to help if it''s a bug in netfilter or shorewall. And thanks to Tom and everyone else on the list assisting! -- Regards, Kim Pedersen Computer & Network Consulting Services Ltd. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Jerry Vonau
2005-Aug-16 13:48 UTC
Re: Problem with DNAT causing martian source messages in log files
Thanks for the update, Kim. Glad you got it to work. Jerry> > Hi Jerry, > > --On Thursday, 11 August, 2005 20:48 -0500 Jerry Vonau <jvonau@shaw.ca> > wrote: > > > Any reason your not using balance as an option here? > > Your trying to reply to 2 inbound networks, give it a try. > > You can tilt the results toward one by using balance= , > > Higher number wins the preference. If that is not enough > > you can use tcrules to force traffic to use a provider > > I didn''t use balance because I wanted to get the issue of the martians out > of the way before adding additional complexity into the fray. (I''ve done > load balancing before, but wanted to use/try the new providers file in > Shorewall, to have it done in a standardised way). > > Interestingly enough, adding the balance option made things work and the > martians go away. > > To me it seems that the track option should be sufficient to achieve what I > wanted. Ultimately I wanted to have balancing in the end anyhow, so with > the balance option in, I am set. > > > For Toms information, here is the output of uname -a: > > 2.6.11-12mdksmp #1 SMP / i686 Intel(R) Xeon(TM) > > At first I was using 2.6.11-6mdksmp, but did the minor upgrade to > 2.6.11-12. I realise that there''s been quite a few changes to NAT/Netfilter > in 2.6.11, so maybe the glitch comes from here? > > Tom, let me know if there is any other information you might be interested > in to help if it''s a bug in netfilter or shorewall. > > > And thanks to Tom and everyone else on the list assisting! > > > -- > Regards, > Kim Pedersen > Computer & Network Consulting Services Ltd. > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf