cmb, Just wanted to say a Thank You, for explaining the conflict scenario as you did. I was running into a similiar situation as the Op here was explaining. Long story short ,On our new school setup between buildings , 10 miles apart, the two pfSense machines are now trunked via fibre rather than our old ipsec vpn setup. I had two different public ip's as CARP ips on each of the pfSense machines but the vhd# was the same on each of these. The port forward would function for about 30 seconds (or less) then quit. I too thought something was flaky maybe. My brain was flaky was the problem. Changing the vhd# up one number fixed the "bug"/ conflict…:) Barry

just know that if they mess up their addressing they can hose you.

Does pfSense have any tools to find a solution?

Your allow to 80 to wan might trigger first? Why did you not just let pfsense create the wan rule for you wen you created the forward?  So the rules would be linked.  You don't want to allow 80 to your pfsense wan IP, you want to allow 80 to be forwarded to your box behind pfsense.  That wan rule says hey if you want to talk to my wan IP on port 80 - its allowed. If it sends traffic to pfsense WAN address first - is there anything listening on pfsense on 80 on the wan interface - if not that explains your closed result. If you want to send 80 to 8099, which seems odd normally it would be the other way because isp blocking 80, etc.. But your rules would look like this - see attached.  Notice the linked symbol on the forward rule. I never understand why users change the default when doing a forward which is to allow pfsense to create the associated wan rule.  I would start over, remove that rule to 80 and 443 you created and let pfsense create the wan rule when you create the forward (default). Also quite often web server firewall needs to allow traffic from internet, quite often it only allows traffic from the local network until its opened up.  And you sure you listening on 8099 on the webserver?  You can access that from the local network? [image: forward80to8099.png] [image: forward80to8099.png_thumb] [image: wan80to8099.png] [image: wan80to8099.png_thumb]

When you use the name, that translates to the public IP address, which goes to the WAN of your pfSense. That is all a bit tricky - the packets are coming from the LAN side and turning up as incoming on WAN, then are port-forwarded back to the server in question. NAT reflection can make that stuff happen OK, but it is easiest to do split-DNS. On your pfSense DNS add a host override for example.com pointing it to 10.0.0.10 - then clients on your LAN cab use "example.com" in their URLs and for them it will translate to 10.0.0.10 and work. User out on the public internet will get the "real" translation of "example.com" to your public IP and use that like they do now.

Nevermind, I finally figured out what the problem is… and the simplest answer is the right one. There were two identical mac addresses. Why? Because I accidentally clicked on the "Insert my local mac address" on the LAN config page, thus spoofing my WAN mac with that of an internal host on my network.... hahahahahahaa.. live and learn I guess.

Port forwarding doesn't break by upgrading. It's almost certainly something that would have happened upon reboot, or in much rarer cases something wasn't right to begin with but worked by coincidence. Why do you have the same port forwards on both vr0 and pppoe0? What does your port forward screen look like? Is 213.xxx.228.27 your correct WAN IP? Could have been manually configured to something static that isn't really static and you got a different IP post-reboot, is why I ask. Is there something else that prompted you to refer to "very strange entries"? Aside from having the same port forwards on two interfaces, the remainder looks normal.

@Derelict: But all you have to change is the interface from pfSense to the 2911 and add a couple routes. They don't even have to know you did it.  And it will all be proper and have multi-wan with failover. The only route they would need to add is one for the new interface addresses and that's only if they want to talk to them directly.  You could also just ask them for a third subnet out of 192.168.0.0/16 for your interface network between 2911 and pfSense. You're right and I am going to look into setting it up like you suggested. The issue I have right now is that they will notice as soon as I make the changes to the interface on the 2911, which will server the connections the the SO and the Jail, which will set a whole string of annoying calls et cetera. So what I am going to do is configure the 2911 to feed both the 113 and 116 subnets over one trunked port instead of two separate ones that they are feeding them over now. That will take a couple of minutes of downtime to reconfigure the interfaces which I can schedule. Then I will have an extra interface on the 2911 I can use to setup the routs and the PFSense box and then switch it all over when I have determined it is working. So first i need to fix their old routing issue then do what you suggested!

@Derelict: And I see rules up there that are TCP only.  Do protocol any.  ping isn't TCP and won't be passed by those.  DNS is usually UDP and won't be passed by those. Yeah I noticed that and changed it. And Its all working for me now  :D And the above explanation helped a lot thanks for all the help!

I have found problem.Because I use command line to login ftp server.I found command line will send Active mode to FTP server even I send "quote pasv" to PASV mode.So,I can login ftp server if I use ftp client software.

I do have multi-WAN but mainly use it as a failover for internet surfing. Thanks for all the replies!  I will have to give it another try and look into the areas that you all pointed out.

You could try using one of google's stun servers on both clients if both clients are behind NAT and behind two separate routers. I'm not sure if it will make a difference for you, but maybe.  Other than using a stun server/ICE, you can use VPN.

all done @kom KVM Setup OS: Linux 3.x Bus: SCSI 0 Storage: local Disk size GB 50 Format: qcow2 cache: no Cache CPU: socket 1 Cores:1 Type: qemu64 memory: fixed size 2048MB Network: NAT mode model: Intel E1000 call up Installer Accept default settings Quick/Easy Install Standard Kernel reboot ============= then it start asking about VLAN y/n and about WAN port and so one and i use: pfSense-LiveCD-2.2-RC-amd64-20141211-0341.iso

So I had a buddy do a sniff with his xbox - and seems the only inbound port is 3074, the 88 is outbound even..  Which makes sense since the xbox would be logging in [image: port88.png] [image: port88.png_thumb]

ISPLAN y.y.y.y/26 are real public IPs. So you just want pfSense to route those, and not do NAT. Firewall->NAT, Outbound - switch to Manual and delete the NAT rules for that y.y.y.y/26 interface. For initial setup and testing put: pass rule on WAN to allow source any, destination ISPLANnet pass rule on ISPLAN allow source ISPLANnet destination any Now put a test device in ISPLAN, you should be able to get out from it to the internet. The ISP should be routing anything for y.y.y.y/26 to your public WAN IP, so get on the real internet and try accessing that ISPLAN test device. It should be reachable. Once you know the routing is working fine, then put more restrictive rules on WAN and ISPLAN to allow only what you really want, and setup the real servers…

How are you validating your port forward?  From pfSense WAN side or from Cisco LAN side?  Does the Cisco know about the pfSense box and routes its Internet traffic through it?