Thanks KOM for your help and your patience.

@nogbadthebad I will give a try to pfblockerng to, I use but not with ASN. Good move.

@jknott i can ping the other end but thru 90.14.x.x however i have 90.11.x.x peer with pfsense on azure and we have nms placed at azure zabbix that is on 90.11.x.x subnet now i want this: pfsense---->customer customer----->pfsense P1 already established P2 also established but with local subnet 90.14.x.x Now i want to reach like this: customer----->pfsense(subnet 90.14.x.x)--- --->zabbix(subnet 90.11.x.x) i can ping90.11.x.x from pfsense but how to transfer traffic from customer 90.14.x.x at pfsense to 90.11.x.x ?

https://www.netgate.com/solutions/pfsense/

@justinxa For using transparent-client-ip i suggest moving the webserver to a different lan / vlan / OPT1 network than from where the clients are connecting from. So traffic to/from it will always pass through pfSense. As for your question about pfSense being on the same subnet, 'yes too all'.. pfSense and the webserver will be on the same subnet also pfSense and the ISP should be on the same subnet AND also client and pfSense would be on the same subnet... pfSense would have 3 nic's one for each network.. (those could be vlan's which are effectively treated as additional nic's) But well needs a managed switch that can be configured to trunk and tag certain ports with vlan traffic.. . Or, use a different solution like X-Forward-For header or proxyprotocol. Either of which would also need to be configured / supported by the (web)-server.. So the chance of these being possible are low if traffic it isn't send to a regular webserver.. And even then might need some extra plugin to support the proxyprotocol. Personally i think transparent-client-ip is the 'most compatible' option.. but well it does require separated client<>server networks....

Anyone? :)

When you talk about FTP, then port 21 among other, get involved. rsync, normally, runs over port 22 - or whatever port (SSH ?) you choosed server side.

@dpettigr said in 3cx smtp services: I have opened SMTP by using this info https://vworld.nl/?p=3644 A rule for an outbound connection ?? Why ? LAN, by default, allows any IP to connect to any port using any protocol.

That worked. Thanks

Thanks for the reply. I have managed to fix it as I have noticed the problem also on my LG TV Netflix. it was due to wifi channel was set to ht40. Amazon fire TV 2 does not like ht40 over 2.4GHZ. I have changed it to ht20 and it has been working fine.

@johnpoz said in Need to understand why traffic is allowed: Dude I have worked on juniper netscreen and srx, cisco pix and asa, checkpoint.. Pretty much its a firewall and I have used it... Not ONE of them sets rules based upon exit of a interface.. First one that comes to mind is a Cisco ASA. Traffic can not flow from a DMZ into a LAN by default due to security levels set.

Yeah if memory serves there was an issue with maybe 2.3 and I had to reinstall everything from scratch. I can't remember what it was, it was a long time ago now. It might have had something to do with schedules or SARG.. I just can't remember but I know when I upgraded I had to reinstall all over, and thankfully I had backed it all up. 2015 was the last time I was there to keep it up I think. I check the box once in awhile, it doesn't spam traffic so maybe it's not been compromised. I originally put it in for both the kids customized rules and to maximize my CoD/BF playing. Boy, did it ever smash the DLink Gamer Lounge I had back then... ah, the good ol' days.

Diagnostics -> Backup & Restore -> Config History -Rico

it sounds like youre trying to do policy based routing, and this is definitely something you can accomplish with PFSense. Youre going to want to define gateways, and in the advanced option of a firewall rule (at the bottom of the rule edit page) you can define a gateway to send traffic to that matches the rule.

where did you perform the packet capture? Start by replicating the issue and performing a packet capture as far from the client as possible, and work your way in. For example: Client -> PFSense -> InSync Cloud Perform a packet capture and verify you see client AND server hellos between PFS and InSync cloud (On WAN interface). Next, perform a packet captrure between PFSense and the client (On LAN interface). Verify if client/server hellos are also present. Client and Server Hellos If present on WAN and not LAN, there is a rule blocking traffic somewhere. Verify Firewall rules, IDS/IPS, geo-protection, and NAT. If not present on WAN nor LAN, verify you're not attempting to access the service from a blocked IP. This is usually common when accessing services via a VPN provider. Things to check for in this case: -Confirm connectivity to the InSync Cloud. Ping, https, etc. anything to confirm you can communicate with the service -Verify client configuration for the backup is correct. I'm not familiar with this particular service, so perhaps the client config has a typo in the user/password, is configured to target an incorrect server, or the application may be throwing event logs explaining the issue. -Lastly, and probably not the case, Take the proposed cipher list from the client hello packet and confirm with InSync that they're configured to accept any of them.

Update - it works from a different PC, so now I know its a problem with this linux machine. The route command comes back with nothing... but netstat -rn output looks good. I'm going to re-do this machine I think.