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

Thanks! It looks like it's working now.

@sullrich:

I had no idea how to fix it but googling tcp auto scaling windows 2003 came up with:

http://thesystemadministrator.com/The_System_Administrator/Tips_&Tricks/Disable_TCP_Auto-Tuning_to_Solve_Slow_Network(Vista)/

thanks for your reply, but i don't think that this is the issue. It doesn'tmatter which OS the Client has. It can be an Win2003 Server, an XP Machine oder a Vista Box. Everywhere its the same Problem. I can receive some secondes every package from my Server - an then no –> the Server doenst response. if i took my m0n0 back, with the same conf --> everything work fine.

Firewall lets every package pass - nat is configured well. what can i do to help you ?

greets,

sash
sashxp@gmail.com

Cheers,

I made that change, and I think I understand a little more about NAT now into the bargain.

Thanks

Ben

Search the forum for NAT Reflection.

You will not be able to do reflection for 1:1 hosts but you can port forward on the WAN interface on top of the 1:1 items for the needed ports.

Alternatively setup another DNS server on the internal network and point the internal hosts to it which overrides the DNS IP address to the internal address.

We have 42 subnests. Here is a example of some.

nat (inside) 12 10.12.0.0 255.255.0.0 0 0
nat (inside) 13 10.13.0.0 255.255.0.0 0 0
nat (inside) 14 10.14.0.0 255.255.0.0 0 0

global (outside) 12 external ip netmask 255.255.255.224
global (outside) 13 external ip netmask 255.255.255.224
global (outside) 14 external ip netmask 255.255.255.224

RTP is being tranfered over either UDP or TCP.
http://en.wikipedia.org/wiki/Real-time_transport_protocol
Since it usually uses a port from 16384-32767 you need to take a look at your webcam config and select the right on for your FW rule.

VNC uses RTP too and there is no problem with is over pfSense.
So i suspect you just used a wrong port in your FW-rule.

Nope, switched it back to https and left the port default and all i get when i got the the web address is a white blank screen. Which I am assuming is the pfsense install.

Hello thanks,

made a change to the configuration. Now the SSL-VPN is in the DMZ and surpringly it now works. Tried to check all differences. Only special thing was a suspicious DHPC reservation for the laptop.

Still wonder what the problem was..

regards,
Hans

Just a dumb question but in the "Interfaces -> Wan" settings are the "Block private networks" and / or "Block bogon networks" check-boxes checked??? If so try un-checking them and see if it helps…

gm...

I personally have the same problem and I do understand the uncheck VPN default gateway option on the client.
However there are employees not capable of doing this
there are peoples that simply would prefer to connect and browse their site from VPN without unchecking that option in pptp VPN, …

Bottom line is it should be pretty simple to add to the code an option to allow proxy arp on the pptp interface.

Is there a way to do it ?

And if you rearrange the drawing a bit you'll see:

┌───────┐                      ┌───────┐              ┌──────┐ 
  –WAN--┤ pfSense ├--LAN---(WAN)--┤ untangle ├--(LAN)--┤ switch ├--(local subnet)-...
              └───────┘                      └───────┘              └──────┘

You said you can reach the Untangle box's SSH port from local subnet side.
Are you sure it is reachable from its WAN side (or whatever it's called) as well? This would explain your problems at least.
But to be honest I don't know a thing about an 'Untangle' box so maybe I am totally off track.

Dude you're doing it all wrong, this exact same thing happened to me a few days ago coz of what I've read in the monowall documentation regarding 1:1 NAT, it's not complete. Although you can mix port forwarding rules with 1:1 NAT, it is not necessary as long as you have that many public ip's available.

This is the procedure you should follow:

1. Create the Virtual Ip's.
2. Mapped the public ip's to the virtual ip's you've created in step 1.
3. Finally create firewall rules allowing a particular service that your server will be providing, (let's say that is a  web server) create a firewall rule in your WAN interface allowing tcp port 80 from anywhere to the private ip address of the web server.

e.g.

TCP  *  *  192.168.1.2  80(HTTP)  *

You also ought to read this thread about 1:1 NAT -> http://forum.pfsense.org/index.php/topic,6965.0.html

HTH

Finally I was able to make 1:1 NAT work by following this thread –> http://forum.pfsense.org/index.php/topic,6965.0.html maybe I was stressed out yesterday that it's why I can't make it to work coupled by the rustiness of not using pfSense for more than a year.  ;D now if only I can make the DNS point to correctly in order to receive mails, currently only outgoing mails is working.

Well the reason i was asking is because Skype was not working on my Mac Mini and I suspected everything.  I could hear fine but could not manage to get my microphone audio to work.    It appears that the newer Mac Minis do not have audio input working even though there is a plug labeled audio in.

So I shoulda figured, my little BSDy is working like a champ as usual.

Skype audio from the test call was excellent.