Resolved: Unidirection inter subnet routing problem
Sorry, this is another one of those - cant route between two subnet problems, but this time it appears to be in one direction only….
em1 LANA - Address 192.168.0.1/24, static IP, all other default
em3 LANB - Address 192.168.2.1/24, static IP, all other default
LANA port ----------> Switch -> PC, etc
LANB port ----------> Switch -> AP and test laptop
On LANB there exist an access point (192.168.2.254) which I need to get access to from LANA for administration. Cannot ping or connect from LANA 192.168.0.x addresses to 192.168.2.x addresses
If I connect a laptop to LANB switch I can access onto the 192.168.0.0/24 network from the 192.168.2.0/24 and get out to the internet, all is fine. Verified I can ping the 192.168.2.254 access point from the 192.168.2.0/24 subnet. Note eventually I want to prevent access to 192.168.0.0/24 from 192.168.2.0/24 but first I need to resolve the routing.
LANA has just three default rules
- IPv4 & 6 LAN net * * * * none - default allow lan to any
- anti lockout rule
- IPV4 LANB net * * * * none - Outbound traffic
- Two easy rules pass from firewall log view - IGMP/ICMP source 192.168.2.0/24 *
No interface groups, vlans, bridges
Windows firewall off. Have used Linux client to verify and a separate laptop. Laptop confirms access from LANB to LANA and verifies failure of LANA to LANB (Note laptop dhcp and each subnet switch has a release/renew to ensure correct IP picked up and tested with subnet local addresses.)
Tried disabling the pfsense firewall and still doesnt route
Also just tried a complete reset of pfsense with only the default any rule and adding an any on LANB. Same result, only traffic from LANB to LANA and not from LANA.
From LANA I can ping 192.168.2.1, cant ping anything else on the 192.168.2.0 subnet
ARP Table shows mac for 192.168.2.1 and 192.168.2.254 AP
Packet capture only shows one way packet. Note 0a:e8:4e:68:11:d3 is the mac for em1 LAN nic
08:15:53.326271 30:85:a9:41:b1:16 > 0a:e8:4e:68:11:d3, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 3159, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.67.60954 > 192.168.2.254.80: Flags ~~, cksum 0xae79 (correct), seq 632489959, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
08:15:53.326484 30:85:a9:41:b1:16 > 0a:e8:4e:68:11:d3, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 3160, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.67.60955 > 192.168.2.254.80: Flags ~~, cksum 0xfe76 (correct), seq 4224573901, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
08:15:53.577268 30:85:a9:41:b1:16 > 0a:e8:4e:68:11:d3, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 3161, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.67.60956 > 192.168.2.254.80: Flags ~~, cksum 0xc231 (correct), seq 802941444, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Nothing showing in the firewall logs
127.0.0.1 link#8 UH 273 16384 lo0
192.168.0.0/24 link#2 U 19768 1500 em1
192.168.0.1 link#2 UHS 0 16384 lo0
192.168.2.0/24 link#4 U 153 1500 em3
192.168.2.1 link#4 UHS 0 16384 lo0
At this point I'm completely stumped. It should just work as there's nothing special.
Is there anything to be run at the command line to give more information on the routing config?~~~~~~
On which interface have you taken this packet capture?
Take one form LANA while you try the same access from LANB to LANA.
The packet capture was from pfsense. Capturing from a pc on .0.67 shows similar.
Ok, so I set up a simple HTTP service on .0.67:8008 and connect to it by the browser from the laptop on .2.33. The wireshark capture shows correct source, mac address is the …:11:d3 (em1 of LANA):
LANA was a mistake, LANB is juicy, the outgoing interface, to see if the packets are passed out there and if responses come back from the Laptop.
So, a capture on the .2.33 laptop is showing as attached. ARP to find .2.1 which is at mac ending at :d5 which corresponds to em3 i/f
These captures show connections from LANB to LANA which work anyway.
For research you should take packet capture from connection attempts which don't work, from LANA to LANB. And take the capture on pfSense interfaces, please.
Ok, so setting up a test service on the .2.33 show I can connect from .0.67 so it appears to be an issue with the .2.254 access point (A TP-Link CPE-510). for some odd reason its not accepting packets from another network so that indicates a problem with its default gateway which I'll go and investigate further. What's interesting is that this device was working ok with a Zyxel USG-20 prior to the change to pfsense which must have been more tolerant??
Many thanks for the assistance.
Note to anyone else with subnet routing issues; If testing, set up alternative test source eg another device running a simple http server, etc so you verify with a known good source and eliminate configuration issues in the other
As a workaround you may set up an SNAT rule for the AP. Maybe that's what also the USG did. I've seen this also on a Fortigate.