ASR is almost never used when there is some kind of state-tracking firewall between the two hosts.  I am not sure of the packet flow, but i am guessing that what is happening is that input tcp packets are entering from a different interface than the one the routing table on the receiving host says to use for the return packets.  fixing this (somehow) would be a good idea.

yes, agreed!  i did this, and my SIP problems all went away.

I have pasted this problem on the VMWare forums and see with them what may be the problem. I will be comming back and give some info. See you later. :-\ Thanks

Hi, sorry, I realized last night I made a mistake when posting the pfsense screenshot. Will post the REJECT one as soon as I can. The router is in Congo DRC which I've left yesterday evening. Will try to get someone to provide me the proper REJECT logs. Thanks again for your help.

Remove the IP addres for the WLAN.  1) you don't want an IP on the bridged interface and 2) you can't have two interfaces in the same subnet anyway.

@dotdash: I remember having to check some box to bypass the firewall for the true statics. This was on the Comcast modem. I forget the exact details. This was it. There is a box that says something like "Disable NAT for True Static IPs". Once that was checked, the rules took effect as required. As Jim mentioned, it is probably a good idea to have an alternate port used and maybe we will standardize on one later but either way this option needs to be enabled on the Comcast modem for this to work. Thanks everyone!

ok, thanks a lot!

thanks everyone for your help.  turning the filter back on so it puts the firewall back into firewall mode and setting the outbound NAT rules, where a rule has the checkbox that says not to do NAT on the outbound packets fixed it. i was still having issues, but upon further inspection of linuix log files i found the clients ip address is being passed through the route based firewall and pam is closing all of the sessions.  so now this may have been the easy part, pam in linuis does not look so easy. no addtional route was needed.  duh - the firewall is the router between interfaces. thanks again!

Thx GruensFroeschli, We made several tests and it works correctly. On your point 1.2, you were right, it was an error in rules, we had a badly placed rule which opened inter-vlans connections. Thank you for your answers. Yro.

OK so that was user error I mean my ….  :-\ I have been trying to experiment with static routes and after I added 192.168.5.1 to 192.168.1.1 and 192.168.5.1 to 192.168.5.119 my whole network went down and DHCP on WiFi router has been changed from 192.168.1.100-192.168.1.120 to 192.168.2.100-192.168.2.120 I am trying to figure it out why that happend. Thank You for Your help. Every message make me closer to what I messed up. MST

@pdxer: If your seeing 'Blocked Log Spam'(high frequency of blocked addresses or ports) an easy way I found to keep it from filling the logs is to write a rule on the destination port in WAN. And since LAN is Default 'All Pass' I will put 'Reject' rules on Ports I know I wont use on the LAN interface, one rule for the source and one for destination. At the bottom of the rule:edit page is a tab for writing logs on that rule, make sure logging for that rule is disabled. This will keep you from getting frequent block logs on your 'System Logs'. To keep your rule page from becoming very long, make an alias for ports(Labeled:BlockPorts) and one for addresses(BlockAddress) that you are wanting to block. So later on when you want to add another port or address, all you have to do is edit the alias attached to the specific block rule. What it looks like is DHT traffic. I'd really rather not ignore it, but somehow get it to actually reach my BitTorrent client.

What kind of devices do you have in front of the different WANs? If they are pfSenses you can enable source NAT and it should work.

I have the same problem here and found the reason in the code /etc/inc/filter.inc line 907 shows $natrules .= "rdr on $tmp_interface proto tcp from any to any port 21 -> 127.0.0.1 port {$tmp_port}\n"; So all traffic to port 21 is redirected to the FTP helper. No chance to configure FTP for different networks. Not that amazing for a firewall. :( Any expert with a workaround here?

Did you create the according firewall rule?

Click the + on the right side.

Find a list of all IPs of antivir-servers. Create an alias, containing all these IPs. Allow this alias.

Hello focalguy, Thanks for the info. I was hoping to get an idea what amount of compensation the developer had in mind to implement something like this, but I guess this is more like post an amount and see if someone bites. I'm now getting a quote from a commercial firewall manufacturer to implement this solution, which is actually what I prefer in terms of what is expected on the pricing front, as opposed to trying to guess what to post in a bounty that may or may not be picked up. If there is an alternate way to get this implemented with PFSense I'm interested. Thanks.

@Perry: Gateway: * (default) fixed my issue, THANKS!!! i will post screenshots when i have everything working properly in case anyone is interested