@rklopoto:

Lately, my users have been complaining about inconsistent ping times.  I verified today that they are right.  From the WAN interface of the machine, I can ping a host and get a decent response:

64 bytes from 66.70.150.19: icmp_seq=0 ttl=50 time=20.554 ms
64 bytes from 66.70.150.19: icmp_seq=1 ttl=50 time=17.849 ms
64 bytes from 66.70.150.19: icmp_seq=2 ttl=50 time=18.575 ms

From a machine behind the NAT, the results are not so great:

64 bytes from broomeman.com (66.70.150.19): icmp_seq=2996 ttl=48 time=371 ms
64 bytes from broomeman.com (66.70.150.19): icmp_seq=2997 ttl=48 time=610 ms
64 bytes from broomeman.com (66.70.150.19): icmp_seq=2998 ttl=48 time=254 ms
64 bytes from broomeman.com (66.70.150.19): icmp_seq=2999 ttl=48 time=256 ms

A reset of the state table drops them back into fairly normal ranges:

64 bytes from broomeman.com (66.70.150.19): icmp_seq=3151 ttl=48 time=53.5 ms
64 bytes from broomeman.com (66.70.150.19): icmp_seq=3152 ttl=48 time=23.6 ms
64 bytes from broomeman.com (66.70.150.19): icmp_seq=3153 ttl=48 time=69.9 ms

At first I thought maybe my state table was too small, so I increased to 50K, from 10K.  I also set the table expiry to "aggressive".  While this helped a little bit, every 30-45 seconds, I will all the sudden get 10-15 packets of high ping times ~500ms.

Are my rules too complex?  Is there anything else I can do to tune this box into better performance?

This is a known bug in pfSense. ICMP packets go for some reason to default queue and it seems your default queue is saturated.

There has been many threads earlier here also.

BR,

Tommi

I ended up going back to the 1-rule "static port for all" setting.  I had forgotten that there are a number of UDP ports for the audio, and I want them to go out unmolested too.  This seemed like a lot of hassle to avoid a problem which is incredibly unlikely to occur (e.g. a source port collision).

1:1 NAT creates a AoN rule behind the scene and also applies the "static port" option to outbound connections.
You allow traffic from and to the 1:1 NATed device with the firewall rules.
You now can not use this VIP for anything else.

With AoN you can create more granular rules.

Have outbound traffic over a certain VIP but still have the option to scrable outbound ports. Forward different ports from the same VIP to multiple servers behind. Be able to have different IP groups go over the same/different VIP (ie: x.10 - x.20 VIP1,  x.100 - x200 VIP2, rest VIP3, pfSense itself normal WAN).

You "can" have the same functionality with manual AoN rules than with 1:1 NAT, but you have a lot more options.
IMO AoN rules together with normal portforwards (with aliases) is a "more proper way" of forwarding ports than 1:1 NAT.

Change the outbound rule from automatic NAT to manual, and then check the box that says "static port" and see if that fixes it.

1:1 NAT requires putting a private IP on the server and mapping that to a public.
If you have to leave public IPs on the boxes, you would want a filtering bridge.
Trendchiller has an excellent doc on this here: http://pfsense.trendchiller.com/transparent_firewall.pdf
It may be getting a little dated, I haven't done a bridge setup in ages.

If you have private IPs also, the most common solution is to create a DMZ bridged with your WAN.

Yes, the pfSense box is a DHCP and a local DNS server. While your suggestion did not work for me, I think I know what's wrong though. I connected to the network with my linux laptop and did some debugging. It turns out that the DHCP server passes some extra domain stuff to their DHCP clients upon registration. I did a cat /etc/resolv.conf file and got:

domain mydomain.com
search mydomain.com
nameserver 192.168.1.1

If I do a nslookup of an existing domain, it returns a proper IP address while doing the same for a non-existing domain i.e. www.somedomain.org returns www.somedomain.org.mydomain.com, and the IP is that of my router WAN interface. Manually removing the domain and search lines from resolv.conf seems to fix the problem. With nat reflection turned on I get proper errors now.

Now I just have to figure out how to fix the DHCP not to serve those domain lines.

@GruensFroeschli:

I'm not sure how pfSense could interfere with that, since it only sees the TCP connection and has nothing to do with the http request.
Are you sure this is not a missconfiguration on the server?

I'm not, but since I can successfully access the website this way when on the same lan, there should be no reason not to access from a remote client. Is there?

Thanks anyway ! Asking me to post the Outbound rules made me think !

I have the same problem… never works.

I am having trouble with getting PFsense to forward the original IP adress of the client, instead of the PFsense LAN IP….

I have followed the guide, but to no avail.....

@GruensFroeschli:

Yes you can do that with VIPs.
With advanced outbound rules you even can get the same functionality of 1:1 NAT where the traffic originating from the server appears as if from the VIP.

Can you give me an example?  What advanced outbound NAT settings would need to be set up to do that?  Because for VPN purposes, I'm certain that the traffic would need to come from the VIP.

In your setup, you are only forwarding port 5000 to port 746 on the inside, is that the only port you wanted to forward?

See reply to other post.
http://forum.pfsense.org/index.php/topic,19664.0.html

Thanks for the reply.

Since I am knew I thought I had to use NAT. Can you explain how I can your PASS rules?

I will try that when I get home, thanks.  I am not sure how that will work though, since the tivo needs to get to the outside world and does have a private IP, so won't "no nat" keep that from working?

No, I am sorry, but it seems that UPnP is not working for me.
Anyone else maybe can help me ?
Come on, guys, there must be some way of doing this..
Please don't let me down :)

@capsmet:

PS: I considered trying sipproxy, however because I'm running on an embedded system I can not run packages.

Update to a 1.2.3-RC3 snapshot, then you will be using NanoBSD and can install packages, including the SIP proxy.

By default, pfSense will not NAT between internal subnets.

You can customize this behavior by using manual outbound NAT rules.