Only firewallrules.

Can't make rule - all variant's not worked  :'( icmp 10.0.0.21:512 -> 194.87.11.112 0:0 tcp 10.0.0.3:80 <- 10.0.0.21:4977 FIN_WAIT_2:FIN_WAIT_2 tcp 10.0.0.3:80 <- 10.0.0.21:4979 FIN_WAIT_2:FIN_WAIT_2 tcp 10.0.0.3:80 <- 10.0.0.21:4990 FIN_WAIT_2:FIN_WAIT_2 tcp 10.0.0.3:80 <- 10.0.0.21:4996 ESTABLISHED:ESTABLISHED tcp 10.0.0.3:80 <- 10.0.0.21:3007 FIN_WAIT_2:FIN_WAIT_2 tcp 205.189.214.250:80 <- 10.0.0.21:3015 CLOSED:SYN_SENT tcp 10.0.0.21:3015 -> 10.0.0.3:50325 -> 205.189.214.250:80 SYN_SENT:CLOSED udp 10.0.0.21:3002 -> 10.0.0.3:51822 -> 192.168.2.20:53 SINGLE:NO_TRAFFIC udp 10.0.0.21:1103 -> 10.0.0.3:52415 -> 192.168.2.20:53 SINGLE:NO_TRAFFIC udp 192.168.2.20:53 <- 10.0.0.21:1103 NO_TRAFFIC:SINGLE udp 192.168.2.20:53 <- 10.0.0.21:3002 NO_TRAFFIC:SINGLE udp 192.168.2.22:53 <- 10.0.0.21:1103 NO_TRAFFIC:SINGLE udp 192.168.2.23:53 <- 10.0.0.21:3002 NO_TRAFFIC:SINGLE udp 10.0.0.255:137 <- 10.0.0.21:137 NO_TRAFFIC:SINGLE udp 10.0.0.21:1103 -> 10.0.0.3:62050 -> 192.168.2.22:53 SINGLE:NO_TRAFFIC udp 10.0.0.21:3002 -> 10.0.0.3:53304 -> 192.168.2.23:53 SINGLE:NO_TRAFFIC udp 10.0.0.21:137 -> 10.0.0.3:53734 -> 10.0.0.255:137 SINGLE:NO_TRAFFIC Rule NAT interface:WAN  src:10.0.0.21/32  dst:ANY trans:INTERFACE ADDRESS all ports=any(blank) This rule i copy from default and change src

@hoba: a) 1:1 NAT actually does modify IP adresses but only in one direction like any other natting solution does too. It is just a combination of portforward and advanced outbound NAT. b) yes, it's working as designed and this is not a limitation. I think you have a wrong understanding what 1:1 nat does. Allright, so I see the argument for a) as working correctly. Sounds like there's no other workaround for b) though. Thanks for the info hoba, it's MUCH appreciated!!

I did setup something similar using 3com APs and all is still working perfectly. What I did is : Vlan conf on NIC rl1: SSID 1: Vlan 4 SSID 2: Vlan 5 APs conf: APs mapping each SSID on the correct Vlan, Administration of the APs enabled for wired access only, no vlan on the "admin" link. Network interface on pfSense: RL1 : 172.16.1.0/24   network for monitoring the APs so each AP got an ip in this range RL1/VLAN4 : 172.16.2.0/24 network for first SSID, the public one unencrypted and broadcasted(DHCP and captive portal enabled, limited traffic by firewall rules) RL1/VLAN5 : 172.16.3.0/24 network for the second SSID, the private one that is encrypted (WPA2 PSK AES) and not broadcasted (DHCP enabled, all trafic alowed) So I've got a network for the APs themselves, usefull for monitoring it ;-) and two other networks for each SSID. Firewall rules prevent public traffic from going to private networks.

As your WAN is a private IP-Adressrange make sure "block private IPs at WAN" at interfaces>WAN is unchecked (it's enabled by default). In case your firwallrule was autocreated when adding the NAT i doubt that the problem is at the pfSense end. You might want to add a "log" for the rule that covers this NAT. You should see a pass event at system>systemlogs, firewall logs when trying to establish the connection. If that doesn'T happen it most probably gets stuck in the router in front of the pfSense.

Just for fun, does it make a difference if you create the NAT and firewallrule to allow tcp and udp for this port? How do the nat reflection rules in /tmp/rules.debug look like?

Make sure you have entered some dns servers at system>general (if you WAN is not DHCP or PPPoE). Nothing to do next. LAn clients are now able to go to the internet and everything incominng at wan is blocked by default. Everything else depends on what you want to do but you already have basic connectivity.

thnx for all :|

Maybe a 1.1 feature, but don't take this as a promise. However (like always) patches accepted.

Thanks for the fast response. I believe it's involving Rendezvous/Bonjour, which looks like it can work with multiple subnets, but not without some DNS wizardry… I'm not sure Tivo would be able to use PTPP, so I'm guessing I'll have to either bridge or rethink things. :/

The ftphelper is a proxy server that opens up dynamically firewall ports by investigating the control connection of the ftp session when a client and the server communicates. it lives at the firewall itself, so traffic to this destination has to be allowed too. If it wasn't there you had to port forward the additional portrange your server is using and/or use passive/active mode for your connections.

That's pretty simple and I use exactly the same setup at the office even with multiwan: 1. Delete everything you tried to get this connection going as it apperently doesn't work. 2. At system>advanced uncheck "disable nat reflection" at the bottom and save (this will make your public IP portforward available for the internal lan clients) 3. At firewall>nat hit the [+] Icon and add a portforward for   Interface: WAN,   external adress: interface Interface,   protocol: tcp   External Port Range: HTTP - <empty>,   NAT IP: <local ip="" of="" the="" server="" in="" dmz="">local Port: HTTP Auto-add a firewall rule to permit traffic through this NAT rule 4. Save and apply It should work now.</local></empty>

Wont allow me to specify this mask unless I also set my WAN IP to this and I am guessing I will have 0 connectivity at all then?

;D yes, that does the trick!! thaaanx…

Ok, found the explanation to "solved button" http://forum.pfsense.org/index.php?topic=656.0.

Also make sure you are not blocking bogons. Finally check out http://faq.pfsense.com/index.php?sid=64164&lang=en&action=search

Great !! THX 4 help will continue on the german forum ;-) cheers

The easiest (and imo best way too) is to add a hosts alias with the IP adresses of the local audiocodes. Then enter this alias in the red field when running the wizard where it asks for VoIP. Calculate the maximum bandwidth your voipchannels could use (for example 4 channels at g711 is about 4*90kbit/s) and set this in the bandwidth dropdown at the VoIP wizard screen.

As it may cover the topic, I had problems with my old router and VoIP (United Internet), too. Problem was outgoing conections on random ports. But with pfSense and static port option in NAT, the problem disappeard automagically. The only thing you need is the one NAT rule mentioned and thats it. No Problems here anymore. Without any other software as e.g. the already mentioned proxies, you'll have to use a NAT rule. Grey

This was fixed just a few days ago.  cvs_sync.sh releng_1 if you have a full installation.