Hi Kom, Thanks for that, I changed that and it still didnt work. Then realised the backup box had no gateway on its private interface setup.. Gave it 10.10.22.1 as a gateway and it now works fine. Thanks.

ugh, make me manage a split DNS system instead of being lazy cuz it already worked!! Makes sense if you are moving a lot of data but for small stuff, meh.

At around 4:00AM Thursday something happened to the configuration and now I'm seeing an even weirder issue. I cranked up the amount of diffs to keep in config history, but it's a bit late for that. The traffic is flowing from our remote host properly, but there are no rules anywhere for the port forward. Nothing shows for pfctl -sn | grep 9996, pfctl -sr | grep 9996, or grep 9996 /cf/conf/config.xml, but here's the tcpdumps(w.x.y.z being remote ip and a.b.c.d being our WAN ip): [2.2.2-RELEASE][admin@pfSense.localdomain]/root: tcpdump -i bge0_vlan3 dst port 9996 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0_vlan3, link-type EN10MB (Ethernet), capture size 65535 bytes 14:06:58.109928 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.110272 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.110768 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.110951 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.111289 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.111784 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.112125 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.112284 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.571766 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 14:06:58.572108 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464 [2.2.2-RELEASE][admin@pfSense.localdomain]/root: tcpdump -i bge0_vlan4 dst port 9996 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0_vlan4, link-type EN10MB (Ethernet), capture size 65535 bytes 14:07:03.110049 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.110200 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.110541 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.110723 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.111061 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.111402 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.111559 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.111898 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 14:07:03.112237 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464 Here are the states for the port: bge0_vlan3 udp 10.0.0.10:9996 (a.b.c.d:9996) <- w.x.y.z:37625      NO_TRAFFIC:SINGLE bge0_vlan4 udp w.x.y.z:37625 -> 10.0.0.10:9996      SINGLE:NO_TRAFFIC It's "working" now, but if the connection drops I don't think it will start back up again. EDIT: Yeah, resetting states killed it. I re-added the rule with destination set to WAN address instead of any and it's working now. That's probably all it was.

thanks for the reply, johnpoz. i agree, that is how I think it should work. i.e the cisco would not know about the double NAT'ing. oddly, i can get traffic FROM the internet to the network behind the pfsense and return data (i.e. NAT and PAT inwards to the pfsense) but not initiate connections from within. anyway, we have changed the LAN and WAN interfaces on the pfsense, made some other changes and routing traffic through two different internet connections. to be honest, i am surprised the new network topology works but it does. on cisco forum, as well, but probably cannot action their suggestions as the unit is in production and i am not keen on changing the system drastically. thanks again for the reply.

Thank you so much for the advice on the vIPs. The system seems to be working perfectly now.

@beetlejelly: I tried using the "DNS Forwarder Override" using the documentation but it didn't work. Any help would be greatly appreciated. This is probably the best solution. Did you clear your DNS cache before deciding it didn't work? If you need to bounce the public IP back, this is NAT refection. Look under advanced, firewall nat. I would recommend only checking the box 'Enable automatic outbound NAT for Reflection' and enabling Reflection selectively on the NAT rule.

@Phatsta: Actually I tried that. What happens is the rule changes interface, that's all. Maybe I did somthing wrong, but I don't think so. I'll check it again to make sure. Post the NAT and firewall rules. I do this all the time. Not with 3G specifically, but with different providers.

Destination is usually WAN Address.  Do you have the proper firewall rule to go along with the port forward? https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

For SVN server, will I still use TCP/UDP for the protocol? Yes.  The function of the server has no relation to the communications protocol.  It's like asking if I can still drive on the road if my car is a Blue Toyota.  The road is the road and can handle all cars, regardless of maker or colour.

@Baldur: @Derelict: Web server? I think you're looking at your local network when the problem lies elsewhere. I'm more specifically looking at the PFsense box as a whole. What could the router do to prevent email from getting in. If it's not the problem, then it's not my problem. Hey , I guess your friend has configured Offline client(outlook , windows live etc) on LAN PC . In order to diagnose first you have to SSH into Pfsense and from Terminal do to a Telnet to MX of mailserver on Port 995 or 110 (this is configured on offline client)  , are you able to do it?

If I understand your query correctly, what you're looking to do is create an Alias, which you can populate with IP addresses of your choice. You can then assign the alias as the source for the NAT rule and use it in the corresponding firewall rule. Sor for 'WAN IP group', think 'Alias'.

Was using IP alias.. I did read somewhere Proxy ARP IP type should be used when the IP's are in the same subnet, don't know if this is accurate or not. But anyway, problem was, traffic shaper was causing any changes to firewall/nat to not take effect until system reboot. Removed the shaper, and all is good now. Thanks!

Just a follow up : We made the switch 9 days ago and it's been a painless process. Everything was well planned, if I may say ;) Cerberus (the new firewall) was carefully tested by a few selected people before that. The only remaining issue was NAT related, because the servers were not using the new gateway. We chose a saturday to put the new firewall in production. We basically : deactivated the LAN DHCP server on the "old" firewall activated the LAN DHCP server on Cerberus. Turned off the "old" firewall. Shut down and restarted all the servers / VM / network printers / wifi AP so they could use the new gateway. We had to tinker with the vHost/domain server/Terminal server DNS configuration, but it was solved in under an hour. Mainly because I never touch those servers (this is outsourced to a private company), so I had to google my way around to find where to make according changes. I'm now in the process of configuring CARP / pfsync / XML-RPC between the 2 pfsense appliances. Thanks to everyone for their help ! fabrice

And what version of vmware are you hosting these on?  I have not had any issues with port forwards after upgrading to 2.2.2 from 2.1.5 to 2.2 to 2.2.1, etc.. What tools vmware tools are you running?  2.2 is broken with native tools for example. I have to assume your 5.5u2 at min, and what tools?  Your sure its the default rule?  what forwards are not working?  Why don't you enable listing the exact rule in the log, etc.

I have seen this happen once before.  It occurred when I was messing with the shaper, got it into a state in which it wouldn't load (like the percentages added up to more than 100%) then got distracted and went on to something else. Then I wanted to add a port forward and it wouldn't take.  Finally checked my rules with pfctl like you did and saw the warnings familiar to everyone who has configured hfsc. Fixed that and it was all working again. It's unfortunate that the only time you see the queue loading errors is when your configuring queues. The rules reloading later don't generate any feedback and pretty much silently fail. I don't believe my circumstance as something that will just fail later out-of-the-blue.  It was 100% caused by me and 100% correctable.

Well, I simply do not think your configuration state is anywhere near sane. Things like the above are really impossible to configure via the GUI. God knows what else got screwed. Would flush this down the drain and restart from scratch.

Cool.  That must be new in 2.2.  I use manual just about everywhere so I don't see it.