martian packets? no way... [solved...I think...]

martian packets? no way... [solved...I think...]

Postby jiml8 » Jul 29th, '21, 21:47

Here is one that has me completely stumped.

I am having inbound packets from what seems to be a properly configured and routed interface being identified as martian
sources by my Mageia workstation. But not every time, just most of the time.

eth1 on my workstation is directly connected to eth2 on another device that presently is running openwrt (which I am modifying).

The relevant information on my workstation is this:
Code: Select all
root@dadsbox:jiml> ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.11.1  netmask 255.255.255.0  broadcast 192.168.11.255
        inet6 fe80::215:17ff:fe0e:c30e  prefixlen 64  scopeid 0x20<link>
        ether 00:15:17:0e:c3:0e  txqueuelen 1000  (Ethernet)
        RX packets 8164  bytes 621974 (607.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12288  bytes 1601663 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 38  memory 0xfc760000-fc780000 

root@dadsbox:jiml> ip route show table local  (note that I am providing only a relevant excerpt here)
broadcast 192.168.11.0 dev eth1 proto kernel scope link src 192.168.11.1
local 192.168.11.1 dev eth1 proto kernel scope host src 192.168.11.1
broadcast 192.168.11.255 dev eth1 proto kernel scope link src 192.168.11.1

root@dadsbox:jiml> ip route show all
default via 192.168.2.49 dev eth0
72.183.45.0/24 dev vmnet5 proto kernel scope link src 72.183.45.1
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev vlan0 scope link metric 1010
172.16.187.0/24 dev vmnet1 proto kernel scope link src 172.16.187.1
172.16.188.0/24 dev vmnet2 proto kernel scope link src 172.16.188.1
192.168.0.0/24 dev vlan0 proto kernel scope link src 192.168.0.2
192.168.1.0/24 dev vmnet6 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.33
192.168.11.0/24 dev eth1 proto kernel scope link src 192.168.11.1
192.168.12.0/24 dev eth2 proto kernel scope link src 192.168.12.1 linkdown
192.168.218.0/24 dev vmnet8 proto kernel scope link src 192.168.218.1


On the other system, the relevant information is :
Code: Select all
root@OpenWrt:/# ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 00:0D:B9:4D:1E:82 
          inet addr:192.168.11.30  Bcast:192.168.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7775 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7020 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:786740 (768.3 KiB)  TX bytes:408712 (399.1 KiB)
          Memory:f7b00000-f7b1ffff

root@OpenWrt:/# ip route show table local
broadcast 127.0.0.0 dev lo scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo scope host  src 127.0.0.1
local 127.0.0.1 dev lo scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo scope link  src 127.0.0.1
broadcast 192.168.2.0 dev eth0 scope link  src 192.168.2.61
local 192.168.2.61 dev eth0 scope host  src 192.168.2.61
broadcast 192.168.2.255 dev eth0 scope link  src 192.168.2.61
broadcast 192.168.11.0 dev eth2 scope link  src 192.168.11.30
local 192.168.11.30 dev eth2 scope host  src 192.168.11.30
broadcast 192.168.11.255 dev eth2 scope link  src 192.168.11.30

root@OpenWrt:/# ip route show all
default via 192.168.2.1 dev eth0  src 192.168.2.61
192.168.2.0/24 dev eth0 scope link  src 192.168.2.61
192.168.11.0/24 dev eth2 scope link  src 192.168.11.30


Note that the remote system properly recognizes the route on eth2, but does not have an entry for 192.168.11.1 which is the IP address of eth1 on my workstation.

Here is an excerpt from tcpdump taken on the workstation, while a ping from the workstation to the other device is underway.

The ping goes like: "ping 192.168.11.30" - nothing special here.

Code: Select all
root@dadsbox:jiml> tcpdump -i eth1                     
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:23:33.225711 IP dadsbox.homegroup > 192.168.11.30: ICMP echo request, id 15879, seq 302, length 64
12:23:33.226217 IP 192.168.11.30 > dadsbox.homegroup: ICMP echo reply, id 15879, seq 302, length 64
12:23:34.249717 IP dadsbox.homegroup > 192.168.11.30: ICMP echo request, id 15879, seq 303, length 64
12:23:34.250237 IP 192.168.11.30 > dadsbox.homegroup: ICMP echo reply, id 15879, seq 303, length 64
12:23:35.204273 ARP, Request who-has dadsbox.homegroup tell 192.168.11.30, length 46
12:23:35.250703 IP dadsbox.homegroup > 192.168.11.30: ICMP echo request, id 15879, seq 304, length 64
12:23:35.251143 IP 192.168.11.30 > dadsbox.homegroup: ICMP echo reply, id 15879, seq 304, length 64
12:23:36.244278 ARP, Request who-has dadsbox.homegroup tell 192.168.11.30, length 46


Notice that we see what looks like a normal request/reply chain for the first two packets, but nothing prints on the console that is doing the ping. Then, after the second packet, there is an ARP request from the other device, which does NOT receive a response from the workstation.

This then becomes the pattern; except that after a few more packets the ICMP echo replies stop and all we have is echo request followed by ARP requests.

When the ARP requests start coming through, I start seeing this in the log:
Code: Select all
Jul 29 12:24:06 dadsbox.homegroup kernel: IPv4: martian source 192.168.11.1 from 192.168.11.30, on dev eth1
Jul 29 12:24:06 dadsbox.homegroup kernel: ll header: 00000000: ff ff ff ff ff ff 00 0d b9 4d 1e 82 08 06
Jul 29 12:24:08 dadsbox.homegroup kernel: IPv4: martian source 192.168.11.1 from 192.168.11.30, on dev eth1
Jul 29 12:24:08 dadsbox.homegroup kernel: ll header: 00000000: ff ff ff ff ff ff 00 0d b9 4d 1e 82 08 06


Does anyone see any reason this might be happening? I'm baffled.
Last edited by jiml8 on Jul 30th, '21, 00:19, edited 1 time in total.
jiml8
 
Posts: 1191
Joined: Jul 7th, '13, 18:09

Re: martian packets? no way...

Postby jiml8 » Jul 30th, '21, 00:12

OK, I may have found the problem...or, I may have introduced another (yet to be identified) problem.

Basically, I am doing policy based routing.

My workstation has its choice of two upstream gateways; a VPN gateway that is implement using a raspberry pi, and the default gateway provided by my router.

I have the workstation configured to always use the VPN gateway.

Now, I often have devices that I am developing connected to either eth1 or eth2 (or often both) on my workstation, with my workstation doing SNAT to route this traffic through my workstation and to the internet. For these devices, I don't want their traffic to go through the VPN, so I set up a routing policy that says "anything coming from eth1 or eth2 goes through the box and out the default gateway".

I set that up with these rules:

Code: Select all
# traffic from eth1 or eth2 goes to gateway 192.168.2.1 while
# all other traffic from the workstation will be pushed through
# the vpn gateway

#echo 200 default_isp >> /etc/iproute2/rt_tables
ip rule add from 192.168.11.0/24 table default_isp prio 1
ip rule add from 192.168.12.0/24 table default_isp prio 1
ip route add default via 192.168.2.1 dev eth0 table default_isp


It seemed to be working.

But, now, my unit under test needs to be accessed through either eth1 or eth2 using ssh, and I was having trouble making that work, which led to my earlier post.

After studying things, and tearing my hair out, I took a look at that policy based routing setup, and noticed that there was a route directing traffic from those interfaces to the default gateway, but there was no rule directing inbound traffic to those addresses...and policy-based routing overrides default routing.

So, I added two new routes, and the problem went away.

Now the script that sets up that routing looks like this:
Code: Select all
# traffic from eth1 or eth2 goes to gateway 192.168.2.1 while
# all other traffic from the workstation will be pushed through
# the vpn gateway

#echo 200 default_isp >> /etc/iproute2/rt_tables
ip rule add from 192.168.11.0/24 table default_isp prio 1
ip rule add from 192.168.12.0/24 table default_isp prio 1
ip route add default via 192.168.2.1 dev eth0 table default_isp
ip route add 192.168.11.0/24 via 192.168.11.1 dev eth1 table default_isp
ip route add 192.168.12.0/24 via 192.168.12.1 dev eth2 table default_isp


I'm fairly new to policy based routing. While it provides some incredible capability, it also creates many new opportunities for things to go wrong. And I have to get used to looking at the policy routes in all the tables and not just the default or local tables.
jiml8
 
Posts: 1191
Joined: Jul 7th, '13, 18:09


Return to Networking

Who is online

Users browsing this forum: No registered users and 1 guest