@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

Thanks for the reply!  I will stand by in anticipation  ;D You guys are the best!

I added it to our "not ready yet but cool to have at some point" feature list. Stay tuned  ;)

If you are running on a full install issue the following from a shell prompt: cvs_sync.sh releng_1 && /etc/rc.filter_configure Then make sure the FTP helper is enabled for the interface in question (I am guessing LAN). Also, if you are using a dual wan, then FTP will not work on the 2nd WAN.q

@sullrich: Yes.   We are not geared for the same hardware. If we where, what would be the point of the fork? Makes sense, thanks again for the help. I'll swap the machine for a Pentium III with some decent amount of RAM and see if things improve.