Basic Dual WAN setup help
-
I have a basic dual WAN setup (not load balancing yet). The 2nd WAN comes in the OPT1 interface and is set up correctly as far as I know.
As far as the LAN is set up, I have two VLANs directly connected to pfSense:
172.16.20.0/24 - VoIP VLAN
172.16.30.0/24 - Data VLANI have incoming traffic figured out. All VoIP traffic comes in on the WAN interface, and everything else comes in on the OPT1 (WAN2) interface.
I'm having problems with outgoing traffic though.
My problem is that I can't get any traffic to go out the OPT1 (WAN2) interface. When doing a traceroute, the path dies at pfSense.
Under LAN rules of firewall page:
All traffic from network 172.16.20.0 -> gw WAN works, and follows correct route
All traffic from network 172.16.30.0 -> gw OPT1 (WAN2) does NOT work whatsoever, no traffic flows any further than pfSense
Default rule -> gw WANI have updated to the latest version of pfSense…any ideas?
-
Sounds like a firewallrule issue to me. You should have 4 interfaces in this scenario:
WAN
OPT1WAN
VOIP(VLAN)
DATA(VLAN)Please show us your rules for the interfaces VOIP and DATA.
-
Hmmm, well I don't have two LAN interfaces in my pfSense box…just one.
All LAN traffic comes through that one interface and then out the WAN interfaces (including the OPT1/WAN2 interface).
I have static routes defined in pfSense to my Layer 3 switch that handles the VLANs, and all traffic moves around ok.
My LAN interface is set to allow any outgoing traffic to anywhere.
However, when I want to direct traffic based from sources:
172.16.20.0/24 (VoIP VLAN)
172.16.30.0/24 (Data VLAN)Out different gateways, it doesn't work. It WILL work if I push it out the WAN interface, but it WILL NOT work if I change to the OPT1/WAN2 gateway.
Ideas?
-
Show me your rules at LAN and your static routes at the pfSense please.
-
Attached are the LAN rules and static routes.
Routing out 75.13.22.118 works fine (the VoIP subnet). It's the routing through the 75.13.22.134 gateway that doesn't work (also happens to be on the OPT interface).
The IP address of the pfSense box is 172.16.10.1.
The gateway/router defined in the static routes page is 172.16.10.254, which is the Layer3 switch that handles routing.
Thanks!
-
Do I get this right? You have 2 gateways at one pfSense interface(OPTx)? This won't work. You need real interfaces with a gateway on each. You can make this work with vlans but in your current setup it won't work.
-
No, no I only have one gateway on OPT1. The other gateway is on WAN.
I can push traffic to the gateway on WAN from either LAN subnet, but not through the gateway on OPT1.
Thanks for your patience.
-
75.13.22.118 and .134 sounds like it could be in the same subnet when used with a wrong subnetmask. Are you sure your subnetmaskcalculation is correct? They shouldn't conflict.
-
The subnets are calculated correctly.
This is what's weird. The 1:1 NAT mappings that I have set up through that gateway follow that gateway, so I know it works. Also, incoming traffic through that gateway works as well.
The only problem is directing traffic through that interface (OPT1) from the LAN from a certain network. Directing traffic through the WAN interface works just fine.
I'm stumped.
-
I wonder if this is an outbound NAT issue. Does it work if you create custom mappings for the internal subnets at firewall>nat, outbound? Enable advanced outbound NAT and create NAT rules for all your LANs.
-
I'll give that a try and post back. Thanks!
-
There's something wrong here. I thought I was doing something wrong at first, but now I'm not thinking so.
I can direct traffic from either network through the WAN interface (outgoing). But I cannot direct it through the WAN2 interface (OPT1). I know it is set up correctly, because I can get traffic IN through the OPT1 interface. I also have several 1:1 mappings through the OPT1 interface and they are all working just fine.
Any other ideas? Is this a bug…do I have something configured wrong in the OPT1 interface?
-
Did you try setting up advanced outbound NAT? What rules did you create?
-
Yes I did…no go.
Here's something that's interesting. I enabled logging on the WAN2 interface, the one I'm having trouble with. I wanted to see if this was a firewall blocking issue. See the attachment. The firewall PASSES the packets, but I get nothing back!
This is further evidenced by the website not coming up in the browser, AND the traceroute dying at pfSense:
Tracing route to www.edwards-itc.com [64.38.14.242]
over a maximum of 30 hops:1 8 ms 10 ms 9 ms 172.16.30.254
2 * * * Request timed out.
3 * * ^CHop 2 should be pfSense. Here's a tracert of traffic going out the WAN interface:
Tracing route to www.edwards-itc.com [64.38.14.242]
over a maximum of 30 hops:1 13 ms 10 ms 10 ms 172.16.30.254
2 <1 ms <1 ms <1 ms nexus.youthcue.org [172.16.10.1]
3 <1 ms <1 ms <1 ms adsl-75-13-22-118.dsl.snantx.sbcglobal.net [75.1
3.22.118]
4 8 ms 7 ms 7 ms 192.0.2.100
5 8 ms 8 ms 8 ms dist2-vlan50.snantx.sbcglobal.net [151.164.17.13
1]
6 7 ms 8 ms 8 ms bb1-g1-3-0.snantx.sbcglobal.net [151.164.17.230]7 15 ms 15 ms 15 ms bb1-p7-0.rcsntx.sbcglobal.net [151.164.191.109]
8 15 ms 15 ms 15 ms bb2-p4-1.rcsntx.sbcglobal.net [151.164.191.122]
9 16 ms 16 ms 16 ms ex1-p12-0.eqdltx.sbcglobal.net [151.164.40.29]
10 15 ms 15 ms 15 ms asn6939-hurricane-electric.eqdltx.sbcglobal.net
[151.164.249.198]
11 42 ms 42 ms 42 ms pos0-1.gsr12416.ash.he.net [66.160.184.14]
12 49 ms 48 ms 48 ms pos4-2.gsr12416.nyc.he.net [65.19.129.6]
13 56 ms 56 ms 56 ms pos2-1.gsr12012.chi.he.net [64.71.157.62]
14 80 ms 80 ms 79 ms g2-0.gsr12012.cf.fastservers.net [216.218.230.21
8]
15 80 ms 80 ms 80 ms mercury.fastservercore.com [64.38.14.242]Trace complete.
Goes right through.
-
When using loadbalancing you won't see the pfSense in a traceroute. It's forwarded firectly to the upstream gateway of the interface. This is normal and no evidence that pfSense doesn't work. Can be as well be your upstream gateway on that interface or something else. Not sure what to say besides make sure you are on the latest snaphsot and maybe restart the configuration from scratch. You must have something wrong. Even if that link is down and your monitoring is set up correctly it should work as this link then gets excluded automatically within 5 seconds.