Dealing with asymmetric routes
-
Since you PMed me to look at this:
It seems like there is some good advice going around here, but there may be some salient details that get lost in writing.
I think you should really post a diagram of your network in a form like johnpoz did. (Even if you do it in mspaint :D ).In general:
1. No, there is no "hardcoded" restriction against 192.169/x in PFSense.
2. Get rid of 192.169/16 (unless of course you are indeed RGnet).
3. Generally don't route your own networkHowever, in my opinion is would be acceptable to route a supernet of your own network as shown in the attached diagram I just drew.
(Provided that 192.168.16.2 also has a 192.168.0/24 route via 192.168.16.1).
-
Typo in your drawing there namezero or missing info?
your routing 192.168/16 via 192.168.16.2 but you show default gateways of 192.168.16.1 and 192.168.0.1 ? That would be bad practice as well.. You have 2 default gateways.. Yes if you have a more specfic route that route should be taken. But your metric for your lan interface (assuming that from way your drawn) is going to be much better - so why not take that route to try and get to 192.168.2.128/25 ?
Draw your setup up please labasus then we can all work off same picture to what your doing wrong other than the stuff already pointed out ;)
-
No, I meant 192.168.16.1 is on the other interface (upper line) connecting it via another network segment to 16.2.
visio only lets me draw one text box per object.
-
Ah that makes more sense - name of router is "default gateway"
like this
192.168.16.1 - router - 192.168.0.1
You can add as many text boxes you need on a drawing
-
Yes, exactly! Apologies if the diagram was duplicitous.
16.2 will then have more specific routes for the remote nets.
Are those text boxes linked to the object or just "dangling" nearby?
Either way, a diagram like that by the OP would greatly facilitate things here.
-
For example, we use something like this on the small remote sites (10-20 devices)
Do note though that especially when you bypass FW rules for traffic on the same interface, you shouldn't have multiple subnets on the same Layer 2 segment.
Edit: Also, if you don't want anyone talking to the VPN gateways on the VPN subnet, you should block this via firewall or alternatively move the dedicated subnet past 10.0.16.x to exclude it from the /20.
-
Here it is… network topology (to see attached files - registration required)
If you will have some questions just ask, I can update this scheme with more details, if smth will be missed.
-
From what I understand, your original issue happens between the 192.168.0.252 MPLS router and the PFSense on the VMWare when communicating from a remote net like 192.168.1.0/24 to VM Server 192.169.0.11, correct?
Does everything work ok when communicating between, for example, 192.168.1.0/24 and 192.168.0.0/24 (Office LAN), and the problems only happen when the IP Alias on LAN is utilized?
Normally, the "bypass fw for subnets on same interface" should take care of the asymmetric routing for the Office LAN; That is, you only have an asymmetric route if "VM PFSense" acts as the default gateway on the network, and the "Office LAN" member has no static route to 192.168.1.0/24 defined.
That's why I'm asking whether the problem only occurs when using the IP Alias.
-
Exactly
From what I understand, your original issue happens between the 192.168.0.252 MPLS router and the PFSense on the VMWare when communicating from a remote net like 192.168.1.0/24 to VM Server 192.169.0.11, correct?
Does everything work ok when communicating between, for example, 192.168.1.0/24 and 192.168.0.0/24 (Office LAN), and the problems only happen when the IP Alias on LAN is utilized?
Normally, the "bypass fw for subnets on same interface" should take care of the asymmetric routing for the Office LAN; That is, you only have an asymmetric route if "VM PFSense" acts as the default gateway on the network, and the "Office LAN" member has no static route to 192.168.1.0/24 defined.
That's why I'm asking whether the problem only occurs when using the IP Alias.
-
Ok, if it only happens on the IP Alias, could you please post your /tmp/rules.debug file?
Just sanitize the pulic IPs, they don't matter here.