Issues with routing between two interfaces for *non* DHCP clients [solved]
-
I'm having some odd routing issues. I have a pfsense box with two VLANs. Each VLAN has its own /24.
To rule out any firewall issues, I've added a rule for allow from any to any (on both ends).
I can ping clients from one end to the other that have received an IP from the DHCP server. I can however not ping nodes with static IPs from one side to the other.
It does however work just fine if i ping these nodes from the router itself. Any thoughts?
I'm really starting to run out of ideas. The routing tables looks fine with each /24 listed.
Here's the output from a traceroute for one of the DHCP clients (via a node on the other subnet):
$ traceroute 192.168.4.15 traceroute to 192.168.4.15 (192.168.4.15), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) 0.296 ms 0.269 ms 0.265 ms 2 192.168.4.15 (192.168.4.15) 1.696 ms 1.682 ms 1.663 ms
If we now try one of the nodes with static IP, we get this:
$ traceroute 192.168.4.3 traceroute to 192.168.4.3 (192.168.4.3), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) 0.378 ms 0.330 ms 0.317 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * *
Just to verify that this node is indeed up, here I tried pinging it from the router:
[2.1.3-RELEASE][admin@something]/root(3): ping 192.168.4.3 PING 192.168.4.3 (192.168.4.3): 56 data bytes 64 bytes from 192.168.4.3: icmp_seq=0 ttl=64 time=3.800 ms 64 bytes from 192.168.4.3: icmp_seq=1 ttl=64 time=0.566 ms 64 bytes from 192.168.4.3: icmp_seq=2 ttl=64 time=0.560 ms ^C --- 192.168.4.3 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.560/1.642/3.800/1.526 ms
-
Can you traceroute or ping from a static on one side and a DHCP assigned on the other (trying in each VLAN)?
-
Verify that the destination hosts are using a default gateway that knows the route back to the network where the source of the connection is.
-
Thanks kpa.
Like most errors where you bang your head in the wall for hours w/out any progress, it turned out to be stupid simple: lack of gateway.
It was that, combined with shitty consumer grade hardware with very poor configuration options.