VLAN Routing Issue

A Former User · Feb 20, 2019, 8:21 PM

EDIT: Two issues in this thread (sorry about that). The first is an ICMP issue between a VLAN and LAN. This is solved by turning off Windows Firewall. The second issue is an SMB error between a windows host on a VLAN and a NAS on the LAN. This starts after the first 5 posts.

I'm at a loss here.

vl20 with an IP of 192.168.20.1 - devices on this network can ping pfsense (192.168.1.1), the gateway (192.168.20.1), other vlans, and the internet.

devices on this network cannot ping devices in the lan (192.168.1.1)

Here are vl20 rules

and lan rules

Info about the device in vl20

/opt/librenms # ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:C0:A8:14:3B
          inet addr:192.168.20.59  Bcast:192.168.20.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:74239 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5244668 (5.0 MiB)  TX bytes:6179 (6.0 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1159 (1.1 KiB)  TX bytes:1159 (1.1 KiB)

/opt/librenms # ping pfsense.local.lan
PING pfsense.local.lan (192.168.1.1) 56(84) bytes of data.
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=1 ttl=64 time=0.135 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=2 ttl=64 time=0.243 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=3 ttl=64 time=0.141 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=4 ttl=64 time=0.117 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=5 ttl=64 time=0.126 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=6 ttl=64 time=0.315 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=7 ttl=64 time=0.207 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=8 ttl=64 time=0.222 ms
64 bytes from pfSense.local.lan (192.168.1.1): icmp_seq=9 ttl=64 time=0.245 ms
^Z[1]+  Stopped                    ping pfsense.local.lan
/opt/librenms # traceroute windows.local.lan
traceroute to windows.local.lan (192.168.1.3), 30 hops max, 46 byte packets
 1  192.168.20.1 (192.168.20.1)  0.130 ms  0.200 ms  0.448 ms
 2  *  *  *
 3  *  *  *
 4  *^Z[2]+  Stopped                    traceroute windows.local.lan
/opt/librenms #

Perhaps its a misconfigured switch?

Asamat · Jan 18, 2019, 1:59 PM

your firewall rules allow ICMP, so because your PC can ping pfsense, I think there is some problem on hosts behind LAN port (these hosts don't know route to 192.168.20.0/24 subnet) - so you can:

check route table on these hosts (check if these hosts have pfsense 192.168.1.1 as default GW and if there is another route to 192.168.20.0/24 on these hosts)
use Packet Capture on VL20 (to check incoming traffic) and on LAN (to check outcoming traffic) while you are pinging 192.168.1.3 from 192.168.20.59)

A Former User · Jan 18, 2019, 1:59 PM

@asamat Thanks for the reply!

So...hosts behind LAN can ping VL20. Also, these hosts (specifically windows.local.lan - 192.168.1.3) have pfsense as default GW. Not sure how to check "if there is another route to 192.168.20.0/24 on these hosts".

Here is packet capture on VL20 (when pinging 192.168.1.3 from 192.168.20.59)

08:46:38.621234 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 1, length 64
08:46:39.662706 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 2, length 64
08:46:40.687589 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 3, length 64
08:46:41.711651 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 4, length 64
08:46:42.734604 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 5, length 64
08:46:43.758555 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 6, length 64
08:46:44.783578 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 7, length 64
08:46:45.807608 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 8, length 64
08:46:46.830479 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 9, length 64
08:46:47.854570 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 10, length 64
08:46:48.878533 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 11, length 64
08:46:49.752842 IP 192.168.20.107 > 192.168.20.1: ICMP echo request, id 537, seq 1, length 64
08:46:49.752865 IP 192.168.20.1 > 192.168.20.107: ICMP echo reply, id 537, seq 1, length 64
08:46:49.903398 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 12, length 64

And packet capture on LAN with same test

08:48:35.372947 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 115, length 64
08:48:36.396057 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 116, length 64
08:48:37.419947 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 117, length 64
08:48:38.443906 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 118, length 64
08:48:39.467939 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 339, seq 119, length 64
08:48:41.175351 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 1, length 64
08:48:42.219930 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 2, length 64
08:48:43.244906 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 3, length 64
08:48:44.267917 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 4, length 64
08:48:45.291758 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 5, length 64
08:48:46.315775 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 6, length 64
08:48:47.339831 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 7, length 64
08:48:48.363818 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 8, length 64
08:48:49.388796 IP 192.168.20.59 > 192.168.1.3: ICMP echo request, id 340, seq 9, length 64

Asamat · Jan 18, 2019, 3:12 PM

so, these Packet Capture showed that there is no ICMP reply from your host 192.168.1.3 - so you need to check if ICMP is prohibited on your host (Windows firewall) or somewhere between pfSense and this host.

johnpoz · Jan 18, 2019, 3:54 PM

A windows host out of the box is not going to answer icmp from a network other than its local network.. So yeah if you wan to be able to access a windows machine from another vlan you would have to adjust its firewall to allow for the access.

A Former User · Feb 20, 2019, 6:20 PM

Yep. Both of you are right. Windows Firewall was the culprit. Out of curiosity, do you disable Windows Firewall or keep it running?

I have another question/issue related to routing. Hopefully an easy one to fix. I have a Windows VM (192.168.20.3) which is hosted on a NAS device (192.168.1.2) with KVM (Kernel-based Virtual Machine). I receive "Unexpected network error occurred" anytime I try to transfer a file from the windows machine to the NAS device. Moreover, I sometimes see the firewall blocking 192.168.1.2:443 TCP:R, which I'm not sure is related.

Here is a diagram of pfsense and switch. Ports 1,9, and 15/16 are Native Network = LAN and VLANS tagged.

Do I have something configured incorrectly?

johnpoz · Feb 20, 2019, 7:22 PM

@angdigi said in VLAN Routing Issue:

192.168.1.2:443 TCP:R

R would be a RST... If your seeing those blocked you prob have some sort of issues with duplicate packets, etc.

My windows firewall is off, its not disabled. But have zero reason to run a host firewall on my secure and controlled and limited access lan. Only devices I have setup and use are on this network.. So zero need for a host firewall.

A Former User · Feb 20, 2019, 7:32 PM

@johnpoz

How should I go about troubleshooting duplicate packets? I read the following link, as well as the link about Asymmetric Routing, but not sure if it applies.

https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html