IP Alias "Network" not routing right after upgrade to 2.1 RC1
-
Hello,
I was running 2.0.3. I had a LAN port IP of 192.168.1.254/24. On my LAN segment, I had a few legacy boxes on 192.168.0.0/24 that could not have their IP addresses changed or it would mess up licensing (long story). My WAN is a public IP with Comcast Business set static with a default gateway of the Comcast router.
Now, under 2.0.3, to accommodate the hosts with 192.168.0.x/24, I simply added an IP Alias network of 192.168.0.1/24 (as one of these hosts had an IP of 192.168.0.254 and expected a defgw of 192.168.0.1). This did in fact work as expected. The pfsense route table showed both subnets on LAN port.
Now, all things being equal, I upgraded this firewall to 2.1 RC1 in order to test out the new IPSEC NAT, and after reading about post upgrade issues, it appeared that I would be OK in doing this. However, what is happening is baffling me a bit. The IP Alias subnet 192.168.0.0/24 no longer routes to the 192.168.1.0/24. At first I thought firewall rule, but no rule is showing as blocking it that I can see. Further, a tracepath shows that these packet from 0.0/24 to 1.0/24 are actually getting forwarded to the comcast router (the pfsense defgw). Of course, not sure where they go from there, probably La La Land. All I know is they aren't routing back to LAN. Even more of a headscratcher is that packets from 1.0/24 route over to 0.0/24 just fine.
I don't think a firewall rule on LAN is even in play here. And, through straight routing, the routes exist to route these back to LAN, yet they are being handed off to WAN's defgw.
Why would a simple network IP Alias on LAN that worked wonderfully on 2.0.3 not work under 2.1? New config requirement or a bug?
Thanks!
Mark
-
Uhm… May I suggest just using 192.168.0.0/23
-
You may. :) Can you elaborate why and/or what would be different between 2.0.3 and 2.1 that would cause a /24 this setup not to work any more? I am all for getting it working, but also want to understand what's different with 2.1 over 2.0.3 in this regard. Further why 1.0/24 routes to the alias subnet exactly as expected. Thanks!
-
No, I'm afraid. The whole setup sounds like a bad idea from the very start. Keep it simple.
-
So, is a network IP alias not the best way to handle the hosts that have to stay 192.168.0.0/24 on the LAN interface? I suppose could look at VLAN, but the alias seemed simpler and in fact worked beautifully until upgrading. What is so odd is the routing. When I telnet from a 1.0/24 host to a 0.0/24 host, it connects and I can log in just fine. So, return packets are having no issue going from 0.0/24 to 1.0/24 when the session originates from 1.0/24. I would almost say something in the NAT layer is mucking it up. I may run tcpdump on the WAN port from pfsense and see what these packets look like that are getting handed off to the defgw. Something is changing somewhere such that these outbound 0.0/24 packets are no longer recognized as 0.0/24 and are getting sent to the defgw instead back to LAN.
-
Why VLAN? Why aliases? Why routes? Why are you complicating things in such a horrible way? These computers an on the SAME interface. Set it to 192.168.0.0/23 (covers hosts from 192.168.0.1 to 192.168.1.254) and move on!
-
OK, I follow you there. But what I am after is why what did work (and rightfully so) before does not work now. /23 might work in this situation, but not in all. I don't want to just solve this problem, but want to know why because an IP alias is often a simple solution when the need arises. This board is, afterall, a board about problems with the 2.1 branch. I think this is a problem. If you don't know or want to answer to me on it anymore, find business, but you aren't the only one on here. I have used pfsense since its earliest days. So I am not stranger to it. When simple things like this IP alias stop working after an upgrade, if it's a config change requirement or a bug, I need to know (and so may others). I didn't want to open a bug ticket on this if something in config had changed, so I asked here first (like I'm supposed to).
-
There's not even remotely enough information to debug why this (pointless from the very beginning) setup does not work any more. On another note, you apparently introduced some "new IPSEC NAT" here, so it's not even the same setup any more. (You need either two Phase2 entries there, or use the 192.168.0.0/23 "supernet" regardless.)
-
I know there is not enough info here to debug yet. I wanted to avoid the time to do all that by describing it here first in case someone else had already bumped into this. And I haven't done anything with IPSEC yet. In fact, I haven't changed ANYTHING yet except for the upgrade. It was after upgrading that while I was testing everything out that I discovered a host on 0.0/24 couldn't ssh to a 1.0/24 host anymore. And how it was behaving was bizarre. Prior to posting this, I had read of others having some weird issues with IP alias and CARP after upgrading, but they weren't quite the same thing, but may be related. I am next going to sniff the WAN port next and see what the 0.0/24 originated packet IP layer looks like.