next »

[wdavid]

I have a very strange problem with my firewall 1.2.3-RC3 built on Sun Oct 11 03:50:54 UTC 2009
In general I can say that IP addresses that end with the number between 224 and 239 are always "routed" through WAN.
I have a multi wan configuration where the WAN interface is my backup connection and the OPT1 is the main where I have 64 IP addresses NAT-ed to local servers (with CARP and Load balancing/failover)
I have many LAN rules but in general all traffic is routed through a FailOver interface where the OPT1 has priority.
But now when I’m trying to make tarceroute from any computer in the LAN to an IP that ends with 224-239 the route is always through the WAN interface. This makes impossible to access my server from outside for some clients.

Let me repeat, the pattern of the IP is X.X.X.224 - X.X.X.239 where X can be almost anything.

Will try to go back to a previous build, and see how it works. If someone know a stable build pleas drop me a line.

Update 10/13/09 - I've tried to upgrade the firmware to the oldest, the newest and other random builds from http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2 and NONE of them are working correctly. Went back to 1.2.3-RC1 and now it's OK. Next step I will try to reproduce this behavior in a simplified virtual environment.

David.

[wdavid]

I’ve tried to reproduce the problem on a fresh virtual environment and I had the same behavior. I think this is a major issue that needs to be fixed ASAP.
Here is the configuration:

pfSense  1.2.3-RC3 built on Tue Oct 13 03:53:26 UTC 2009

LAN interface (de0)    
IP address   192.168.1.1      
Subnet mask   255.255.255.0    

WAN interface (de1)
IP address   10.1.1.223  
Subnet mask   255.255.0.0
Gateway   10.1.2.1

OPT1 interface (de2)                   
IP address   10.0.0.201                     
Subnet mask   255.255.255.0                   
Gateway   10.0.0.1                   

All the rules and NAT settings of the firewall are the default of the initial setup wizard, except the rule on the LAN where I’m telling that everything from the LAN to be routed through 10.0.0.1 (OPT1 and NOT WAN).


Not so important but both WAN and OPT1 networks are connected to the internet through 2 separate external firewalls.

Client configuration – Windows XP
LAN adapter
IP 192.168.1.100
Subnet mask 255.255.255.0
Gateway 192.168.1.1

Some traceroute examples form the client computer: (explains everything)

C:\>tracert 1.1.1.223

Tracing route to 1.1.1.223 over a maximum of 30 hops

  1     2 ms     1 ms     1 ms  10.0.0.1
  2    20 ms    19 ms    19 ms  222.145.225.175
^C  
C:\>tracert 1.1.1.224

Tracing route to 1.1.1.224 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    16 ms    19 ms    19 ms  85.139.62.193
^C  
C:\>tracert 1.1.1.239

Tracing route to 1.1.1.239 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms    19 ms    19 ms  85.139.62.193
^C
C:\>tracert 1.1.1.240

Tracing route to 1.1.1.240 over a maximum of 30 hops

  1     2 ms     1 ms     1 ms  10.0.0.1
  2    29 ms    17 ms    19 ms  222.145.225.175
^C  
C:\>tracert 54.54.54.223

Tracing route to 54.54.54.223 over a maximum of 30 hops

  1     2 ms     1 ms     1 ms  10.0.0.1
  2     *       29 ms    19 ms  222.145.225.175
^C
C:\>tracert 54.54.54.224

Tracing route to 54.54.54.224 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    14 ms    19 ms    20 ms  85.139.62.193
^C
C:\>tracert 154.154.154.223

Tracing route to 154.154.154.223 over a maximum of 30 hops

  1     2 ms     1 ms     1 ms  10.0.0.1
^C
C:\>tracert 154.154.154.224

Tracing route to 154.154.154.224 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
^C
C:\>tracert 154.154.154.240

Tracing route to 154.154.154.240 over a maximum of 30 hops

  1     2 ms     1 ms     1 ms  10.0.0.1
^C

Conclusion: If the IP address ends with a number between 224 and 240, the LAN rule to route the packet through OPT1 interface is ignored.

[dotdash]

Thanks for reporting this. I thought I had lost my mind. I was doing some tests with 1.2.3RC3 running dual-wan and CP with per-user bandwidth. It was going surprisingly well until I encountered this.
I didn't see an issue filed for this, so I took the liberty of putting one in. (Bug 111)

[geewhz01]

I'm having the same issue with .224-.240 addresses on my wan.  What's even more strange is it seems to route for me as long as the connecting ip isn't also in the .224-.240 range.

Andy

[cmb]

Confirmed issue, looks like our patch to bypass route-to for multicast traffic has the bits flipped (last octet rather than first). We're looking at a solution.

[althornin]

I just got bit by this also.
I could not figure out why sometimes, while using VZaccess (cellular broadband), I was unable to connect to anything on my network.
I'm basically in the same boat as the OP - my OPT1 (WAN2) interface has much more bandwidth, and is the primary route on a failover loadbalancer pool.

I'm in the process of replacing some linksys vpn routers with pfsense, and this is the last barrier in my way right now.

Thanks for the prompt attention on this issue. 

[althornin]

Just tested this in todays 2GB snapshot, and it works.
Looks like this issue has been resolved.  Thanks for the quick action guys!
Beyond the tracert testing which shows it is fixed, I went to the further step of playing with a laptop with vzaccess until is managed to get an IP ending in .235
That client is still able to correctly connect to the servers - so everything is working.

[wdavid]

I'm running with version 1.2.3-RC3 built on Sat Oct 17 21:42:17 UTC 2009 and everything seems fine now. Thank you quys for the fast answers and fix.

David.