I just encountered this same issue with a Verizon business connection (FiOS, not DSL), and found that using CARP instead of ProxyARP also seems to work, without having to cycle your WAN IP.

look at this post http://forum.pfsense.org/index.php/topic,5748.0.html

keyword: VIP (as in Virtual IP) the search function in the top-bar. http://pfsense.com –> Documentation Also you can install pfSense on your IP330 (again: search function of the forum)

So far so good, things have not gone down since converting to carp.

keyword: policy routing Create a rule at the top of LAN with "source" your IP and "gateway" the interface you want the taffic originating from.

Great thanks so much for your helpfull advice  ;D

Reset states is only needed if you are adding a block rule and you have the suspicion that some connections might already be established that you want to be dropped. Btw, if you click on the block icon in front of the line of the firewalllog you will get a notification which rule triggered this block ;)

May I suggest that you start reading about networking? A possible start could be here: http://en.wikipedia.org/wiki/IP_address http://en.wikipedia.org/wiki/Subnetwork http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing but it's not limited to that. And no, I didn't say your problems arise from false subnetting. Wikipedia has an article about NAT (Network address translation) as well.

I doubt that natreflection (or at least the way pfSense does it currently) will work for a crappy protocol like SIP.

Forgot to say thank you.. Thanks, Mark

Ok m8 Here it goes [image: 1.JPG] [image: 1.JPG_thumb] [image: 2.JPG] [image: 2.JPG_thumb] [image: 3.JPG] [image: 3.JPG_thumb]

Well, I setup up another machine with following those instructions - real basic… Still no good... So I know it's not the pfSense setup (I've setup pfSense countless times in different configs, so I doubted it was setup wrong). Anyway, I think I figured out the problem after watching the traffic on the network interfaces - the switches weren't configured to be in promiscuous mode... I reconfigured and was able to get to one website across the bridged interface. Tomorrow (well, today now, for me), I will go ahead and try it through pfSense. Thanks again... If I still need help, I'll go ahead and post back.

This is an old post but for Search reasons, I thought I would reply. ProxyARP and 1 to 1 NAT do not appear to work for FTP in this case.  There are several articles on the forums and on the net about the issues with Ftp -helper. 1.  Configure the VIP and then create CARP NAT.  Don't worry that you aren't doing true failover - it can work with 1 IP. 2.  Configure Port Forwarding and forward FTP to internal server. 3.  Configure rules on WAN interface to internal server. Worked like a charm for me.

For pfSense, I redid the IP addresses, moving the DMZ to a private net.  Trying to maintain the bridged net resulted in too many complications. In the end however, I ended up moving back to Linux as a base because FreeBSD does not support combining NAT and IPSEC.  I did however keep the DMZ as a private net. Denny

It was a problem from my ISP. It is working now.

Yep, the rule in the firewall has also been updated to * Attached the AON's for the three interfaces. Still not succesful. Did you read my PM ? regards, [image: AON2.jpg] [image: AON2.jpg_thumb]

No. What would you do if the pc was directly connected to the internet.

NAT on pfSense doesn't support RTSP so you really should be looking at a proxy for such thing. But again, i have never used that kind of server so might be mistaken. Try enabling static port as is recommended for VoIP phones, probably that might fix it. Or try setting a 1:1 rule only for the server to communicate if you have a spare ip.

Well, that may be so, but this problem exists before even the 2 pfSense networks try to connect. The error is taking place just trying to connect to battle.net itself. The other odd thing I've noticed is that the 2 different versions of pfSense seem to be setting things up exactly the same. (Which they should) When I run pfctl -sr or pfctl -sn I see exactly the same entries. At least with regard to the settings for port 6112 inbound and the change in the settings for the outbound NAT. But the thing that's consistent is that it doesn't work properly on this end. I wonder if this is effecting anyone else who needs the static-port setting, or if it's just my system? Update: I was able to track down a file for a 1.2RC3 build. It also had the same problems here. It seems to be something with this location. This is very strange because everything else between the 2 locations is very similar, and the firewall here works great for everything else. So far I can't track down any specific reason why this happens. I guess it's just another network oddity.

Would adding 'Source / Dest' rules, for port redirection, be considered a bounty topic? Whilst I am EXTREMELY impressed with pfSense, I think the NAT/Redirection could be improved upon. I now have two troublesome points due to the inability to identify Source Dest IPs/Subnets whilst performing redirection: 1. HTTP Proxy - internal clients need to be manually configured or network topology has to change (first is problematic due to mobile users, second is just not a viable workaround for me). Could be fixed (easily?) with a Source IP/Net scope in the redirect 2. Mail configuration for locally hosted server. Whether this is a bug or not, I can't tell. Here is the scenario: WAN IP resolvable to mydomain.com (for which MX record exists) WAN redirect rule for port 143 to go to mailserver.my.lan on LAN LAN client tries to connect to mailserver with public DNS of mailserver.hosted.com but passthrough does not occur as request comes from LAN (or at least that is what appears to be happening). Setting up a LAN redirect for port 143 is simply not an option due to connecting to multiple IMAP servers UNLESS a Destination IP/Net Scope can be implemented. What would probably be better is that if the outgoing LAN packet resolves back to the router then it be classified as WAN source and dealt with as such. There is another fix (maybe more) if internal DNS registrations for local clients are enabled and the LAN host name matches the public DNS record. And when I say fix, I mean the end user doesn't have to reconfigure their mail client whenever they are outside of the LAN. however, that is not such a great fix if you have more than one domain. Many, many thanks for a superb product in any case! n