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.

@hoba:

Disable the outpost to see if it's causing the issue. What kind of WAN do you have? PPPoE? Other router in front of you? …

I tried to disable outpost now, and it was closed anyway!

I don't know if i have PPPoE (i have adsl2 from Bredbandsbolaget) I dont have any more routers, the pfSense is in the modem directly.

In my old router (Netgear WGR614v6) it's work to have open ports. So i think it is the firewall in pfSense?

ah ha! changed the rule to GRE and we're good to go!

cheers,
darren

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html

Cool, bump the green button if your issues are solved  ;D

Ha! Thanks to you another quick ggogle gave me:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2005-07/0173.html

"Since windows sharing is generally a two way protocol you might find it
a little hard to work with NAT. The name resolution is one thing and the
RPC based authentication is another. "

Thanks, it's great to have a clear answer.  I'm going to try that VPN solution today.

@sullrich:

@sniffer:

@Sharaz:

im not sure why you would access something that is already on your local lan, via its external ip address?  (well i guess other than for testing).

1-To test external DNS
2-To test some rules (The rule are not the same via the Lan NIC and the OPT1 NIC)

But with proxy,  its possible to test it, but you have to search active proxy…

Thanks all for your answer

Has anyone stopped to think of the ramifications of this feature?  ALL traffic that would have been to the LAN would be sent THROUGH the firewall.  What good is that when you could simply run split dns and keep all traffic LOCAL?

Split DNS is possible if you have multiple IPs. I only have 1 and multiple servers on a VMware Server box. This is my home network and don't have money to spend for multiple IPs. So theres no easy way to seperate traffic to the same hostname on different ports to different machines without this feature. Yes you can go directly to the machine name, but for mail its a pain to switch back and forth when your inside and outside the network. Same with web applications that have hard coded address (Gallery is just one of them).

There won't be any change on the aliassystem for pfSense 1.0, but pfSense 1.1 is already under developement. The aliassystem has much improved already in 1.1 and work on it has just started. It's too early to promise anything but we allready discussed something like that in the past. Stay tuned  ;)

@ZGamer:

The problem is that when it creates them that way they cancel out each other and the ports are not accessible from the outside.

If you see a problem how about offering a patch?

I gave up getting it to work. What I did was set the dhcp server gateway in pfsense to point to the squid box. Then I just enabled ipv4 fowarding and created two iptables rules. Yes this puts all dhcp clients no matter what protocol or port through the squid box, but the performance hit is neglibile and will be outweighed by the caching effect. Especially for google maps and live.local virtual earth. All servers still point to the pfsense box as their default gateway.

If anybody wants to duplicate … I'm running fedora core 4, squid setup in transparent proxy mode.

Add/change the following line in /etc/sysctl.conf to enable ip forwarding.

net.ipv4.ip_forward = 1

Then just add the following iptables rules to /etc/rc.local

iptables -A FORWARD -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

The first rule says to accept and forward all traffic received to the default gateway (pfsense) otherwise aim, mail clients, etc wouldn't work. The second intercepts the http traffic and sends it to squid on the default port of 3128.

I also use the following script so I can make changes to squid and restart it without end users seeing.

echo "Stopping Squid Traffic Redireect"
iptables -t nat -F PREROUTING

service squid restart

echo "Redirecting Traffic To Squid"
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

This just clears the iptables then reinstates the rule after squid restarts. You can make modifications of this to stop squid, etc.

Ok, I got it working again. After hours and hours of trying differnet things and then re-reading CAREFULLY the topic of static-routes, I seem to have success.
I was trying to write a new outgoing NAT rule instead of just editing the default one that was already there. All I did was click the "Static Port" box.
I'm going to get some sleep now. Maybe. :)

:-[ Well, I feel stupid now - entirely forgot about the view file feature - Thanks for pointing it out :-[

blah, silly me… :)

thank you both, sullrich and cmb, for answers!

have fun
trip

@aldo:

when attempting to port forward the gre protocol it adds a port definition to the end of the rule with no port.
thus the rule fails to load.

Thanks, fixed in CVS, it should appear in RELENG_1 shortly

–Bill

So, I finally managed to get time to look at the problem. I installed BETA2 (leaps and bounds better than BETA1 in almost every area, thanks everybody!), and I'm glad to say that the static-port did the trick. Quick summary:

Enabled advanced outbound NAT, changed the default outbound rule to enable static-port. Reboot adapter. That's it!

I'm not sure if I still need the following rules on the NAT: port forward page:

WAN  UDP  5060 - 5061  192.168.0.9  5060 - 5061
WAN TCP/UDP 5004 192.168.0.9 5004

Will have to test that.

Thanks to everybody who replied, end everyone who has worked so hard to make pfsense better!

Erik

ok but the host is external not internal. oh well it does not seem to create a problem