Port forwarding on WAN and OPT1 same port, same host…



  • Can it be done? I've been trying alot of different things, based on the different guides mentioned herein.

    All the port forwards I add on the NAT screen work for the WAN connection. If I add the same port to the same host for the OPT1 connection, I get a timed out result.

    Based on everything I've tried… is there actually a way to do this?

    Basically:

    WAN:Port1->Host1:Port1
    OPT1:Port1->Host1:Port1

    Thanks



  • I do this all the time. Create two port forwards, one on WAN, one on OPT. Should be able to access the host from either translate. Post some more details- what type of WANs, etc.



  • Sorry for the wait on my reply.

    WAN is a Speakeasy T1 line with static IP.
    OPT1 is a Verizon 7mb/1mb DSL line with static IP.

    Ignoring the port forwarding for the moment, I created two identical firewall rules for ICMP on both WAN/OPT1.

    The rule for WAN is : Proto:ICMP Source:Any Port:Any Destination:Any Port:Any Gateway:T1 Schedule:
    The rule for OPT1 is : Proto:ICMP Source:Any Port:Any Destination:Any Port:Any Gateway:DSL Schedule:

    Pinging WAN gives me a reply, pinging OPT1 gives me nothing… but the pfsense firewall log note that it "pass in on vr0" when I ping, so its definitely allowing the ping request... im just not getting a response.

    As for the forwarding, I've tried setting the gateways to default, to the interface, etc... nothing seems to work on OPT1. everything, configured the same (except replacing the wan values instead of opt1) works fine on WAN.

    I don't really know... if you need more information, I'll be happy to provide.



  • You should be able to ping the Interfaces themselves, but keep in mind ICMP won't work via a port-forward.
    Try setting your firewall rule like this:
    Proto:ICMP Source:* Destination:Interface Address Port:* Gateway:* Schedule:
    As for the port-forwards, did you create an Advanced Outbound NAT rule for the OPT interface? (Should look like the WAN rule) Past that, a port-forward should work using the auto-create firewall rule. The two port-forwards should look the same except for the Interface and external NAT IP.



  • Thanks… I realize port forwarding wont work for ICMP. I'm probably making a stupid mistake somewhere of course, and Murphy is laughing at me...

    I changed the firewall rules for ICMP like you said and I still don't get a response from OPT1, just WAN. However, in the firewall log I can see that it "pass in on vr0" when I ping OPT1, so pings are getting to the box... they just aren't getting back out, lol.

    My outbound nat is set to Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) with these two rules:

    Interface:OPT1 Source:192.168.1.0/24 Source Port:* Destination:* Destination Port:* NAT Address:* NAT Port:* Static Port:NO
    Interface:WAN Source:192.168.1.0/24 Source Port:* Destination:* Destination Port:* NAT Address:* NAT Port:* Static Port:NO

    In the rules themselves I have the Translation address as the interface... and OPT1 is above WAN, not that I think that is making a difference.

    Also, the port forwarding seems to be getting there as well, but no response on OPT1 again.

    IE, I have SSH port forwarded to the same box on both interfaces...
    When I try to connect to ssh on each interface, they both show "pass in" on the firewall log, and both are forwarded to the right ip (again, in the firewall log). However... theres only two way communication on WAN. OPT1 just gets in, never out.

    Thanks for the help by the way... I have no idea what I'm doing wrong.  ???



  • Odd. Try forcing a machine to use the OPT gateway in your LAN firewall rules (add before the default rule), and see if it gets out. Go to ipmonkey or whatsmyip and verify the public ip is the DSL ip.



  • I think I need to reinstall or something…

    Because no matter what I do under the LAN firewall rules, all traffic defaults out over the T1 (WAN) connection. I even disabled the Lan net default rule...

    I'm running beta-2 btw... but it was upgraded from 1.0.1. Maybe thats why everything isn't working right?



  • A re-install is not a bad idea. Load up a fresh install and get the minimum you need configured to use the WAN and OPT1 running, then see if you can push some traffic out the OPT.



  • Yep, the reinstall fixed it…

    I'm guessing that the upgrade from 1.0.1 to 1.2-beta2 created an issue somewhere.

    Everything is working how I wanted it... thanks for trying to help, dotdash.  ;D



  • @dotdash:

    I do this all the time. Create two port forwards, one on WAN, one on OPT. Should be able to access the host from either translate. Post some more details- what type of WANs, etc.

    Hi!

    Does this mean pfSense will remember from which interface the session came up and use this interface accordingly?  If yes, it would mean that i don't need to do policy routing?  I'm trying to figuring out how pfSense will handle this.

    I'm in a situation where we will move from one ISP to another.  Currently, i have my DMZ hosts nated to OPT1 (Virtual hosts mapped to private addresses).  I want these hosts to be accessible from both WAN addresses, each host mapped with a virtual public address from both ISP pool.  Right now, pfSense is facing ISP's Cisco router using static addresses.  New ISP had his Cisco router installed with new IP pool waiting for us.

    So, to be more clear (using fake addresses):

    Actual WAN:  111.111.111.0/24 ISP1
    Host 1: 111.111.111.10 mapped to 192.168.10.10 (WEB Server)
    Host 2: 111.111.111.11. mapped to 192.168.10.11 (FTP Server)

    Future WAN: 200.200.200.0/24 ISP2
    Host 1: 200.200.200.10 mapped to 192.168.10.10 (WEB Server)
    Host 1: 200.200.200.11 mapped to 192.168.10.11 (FTP Server)

    Host 1: Default Gateway 192.168.10.1 (address of pfSense "DMZ" interface)
    Host 2: Default Gateway 192.168.10.1 (address of pfSense "DMZ" interface)

    So:

    1. How to handle default-gateway settings in pfSense perspective when i will configure the new interface to ISP2?  I don't want to do BGP!

    2. What is actually happening inside pfSense when a session is coming from virtual ip 111.111.111.10 and 200.200.200.10 (to the WEB server from his 2 Virtual Addresses)?  Does a session get in/out the right interface with the proper virtual address?  No need for policy routing?

    3. I don't mind load balancing during the transition, i just want to transfert the network and have both wan up until the DNS changes catch up.  Traffic from our LAN can all go to our actual ISP until we are sure that all connections to our servers are coming from the new ISP IP address pool.




  • Forgive me If I miss some details, I kind of skimmed your post. But I think your situation should not be a problem. If a server is pointing to pfSense as the default gateway, then it can return traffic via either WAN connection. If the traffic comes in via WAN1, the reply will go out WAN1, etc.  You can thus have the server answer requests from two separate public IPs from two separate ISPs. You can then get everything running on WAN2, switch the DNS record from 111.111.111.10 to 200.200.200.10, wait a week or so and then get rid of the original ISP.
    So, 1) you should have no need for BGP- you generally would only need BGP if you needed both ISPs to advertise both blocks of publics. 2) This should just work 3) The outgoing traffic is a separate issue- you could just switch it to the new line once it's turned up.



  • @dotdash:

    Forgive me If I miss some details, I kind of skimmed your post. But I think your situation should not be a problem. If a server is pointing to pfSense as the default gateway, then it can return traffic via either WAN connection. If the traffic comes in via WAN1, the reply will go out WAN1, etc.  You can thus have the server answer requests from two separate public IPs from two separate ISPs. You can then get everything running on WAN2, switch the DNS record from 111.111.111.10 to 200.200.200.10, wait a week or so and then get rid of the original ISP.
    So, 1) you should have no need for BGP- you generally would only need BGP if you needed both ISPs to advertise both blocks of publics. 2) This should just work 3) The outgoing traffic is a separate issue- you could just switch it to the new line once it's turned up.

    All right, thanks for your response!

    I was already preparing for the switch, lowering our DNS TTL and having a new DNS ready on the new network.

    For people that will read this thread, BGP stands for Border Gateway Protocol and is a routing protocol used on the internet to advertise routes to autonomous systems (AS).

    I use BGP for big networks that want to have full redundancy to their AS.

    I asked my question here because i don't use pfSense everyday, i'm a network engineer that use Cisco most of the time.

    In this case, my client use pfSense which i don't master to a degree of knowing the inner way of doing things.  All i can say is that pfSense is an impressive piece of software!  I use it more and more for my clients.

    I'll just try it and see the results.  I'll post my observations here for thread completion.

    Thanks again!



  • Hi all,

    I finally had to rely on policy routing.  pfSense didn't seem to be able to cut it without helping it with policy routing.  Had to add secondary addresses to all of my servers, primary address "pointing" to virtual address on provider 1 ("old" provider), secondary to provider 2 (the new provider).  Then i added rules for policy routing.

    I couldn't get the PPTP server to work on the OPT2 (interface to new provider).  Wasn't a big deal because i replaced the "temporary" 4 interfaces firewall with a new 3 interfaces one once changes to DNS propagated.  I relied on SSH + port forwarding to access my servers while the 4 interfaces firewall was on duty.

    I'll probably make more testing with a simulated network inside VMWare.  I'm now searching for a kind of "network director", hopefully a pfSense software plugin that would limit the number of video streaming connections when bandwidth is getting maxed out.  Ideally, the client that wouldn't be able to connect because of BW exhaustion should be redirected to a WEB page instructing him to try to connect later.  I already use the excellent traffic shaper of pfSense but that is not enough when bandwidth is getting fully used.


Log in to reply