@pneumoboy: Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you: 192.168.1.0/24 VLAN1 192.168.4.0/24 VLAN2 192.168.44.0/24 VLAN3 Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4. My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate. I have this configuration setup, but for me the rules are negated by the "Default deny rule" and any connection to the other VLANs are dropped by the firewall. Any ideas of what  a possible problem is?

Yup. Thank you for citing original source.

It could be. I'll check it out. I've disabled ftp-user proxy and the lgos are gone. Don't have need for ftp from lan.

Never seen that unless the server isn't actually responding. Get a packet capture of the internal interface where the server resides when it fails and see what's happening on the wire.

I realized that I did not have outbound NAT static mapping the UDP ports, and appears all is well now that I enabled outbound manual NAT. I had to open all other ports to NAT as well (any to any) at the bottom of my NAT entries to get everything to work.

Thanks GruensFroeschli!!! This seems to be the problem(or not, because there is no problem ;) )!!! Thanks again.

you need to forward ports 10000-20000, and check your sip_nat.conf file there some info you need to add there. check the forums http://www.trixbox.org http://www.pbxinaflash.com They are both based on asterisk.

Yes, it should disconnect active sessions when the rule schedule is in effect (or stops taking effect, depending on if you did a pass/block), but IIRC there is a difference in reloading the rules and the rule going into/out of its scheduled time.

I've figured it out already! The correct firewall rule was: pass quick proto tcp from any to any I guess this can be made more secure by narrowing it down, but for now I'm happy with a working IPv6 link! :D

First, start by defining what you need people to be able to do…

can you ping the server from the clients. if yes then it might be an issue with the port on the mail server. either way you should create a rule from LAN dirrectly to the mail server ip for any port and try the app again. being sure to ipconfig/flushdns on test client and routes on pfs box too for good measure.

I'm not sure what might be causing the replication error, but before you go any deeper into troubleshooting, upgrade those firewalls to pfSense 1.2.3. 1.2.2 is rather old, and that is the only way to be sure that whatever bug you are encountering hasn't already been fixed somewhere along the line.

Thanks Jimp!

Grrrr, ok, problem solved. And of course for documentation reasons here my solution: I does make a difference in which order the ports in your Alias appear. I do have a RewriteRule in Apache that rewrites everything from http to https and although this was not directely the problem it did mess in some way with pfSense. Now I set 443 as my first port in my alias and at least https works. Via http a correct rewrite still isn't done but at least it works in some way now. Via http I get: Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please.    Hint: https://myurl.com So either my apache rewrite is incorrect (which I am pretty much sure it is not) or pfSense does not really handle Aliases in Port forwards correctely. It seems to me that the forward does not try to map external and internal to be the same but does map them in the order they appear in the aliases which would be a quite stange behavior.

It's sort of vague what that is talking about. That may just be for configuring an outbound connection from your server, in which case that would be done on the firewall software there if there even are any outbound restrictions. If you don't have the default rule to allow all traffic outbound, you will need to add entries allowing traffic from your server to those IPs on those ports. (most people have the default allow all outbound rule and thus would not need to do that step) On the outside chance that they are talking about inbound connections coming from those IPs, you can do that too. First you'd have to setup a port forward for those two ports to your internal server, and check the box to automatically add the firewall rule. Next, go to your WAN firewall rules and edit the rules that were put there automatically and enter the IP addresses into the 'source address' box.