External IP source lan>wan, traffic blocked at firewall?
-
I recently setup PFsense to replace an aged IPCop install in production here. Mostly it has been working well for us, but we have some traffic being blocked I can't seem to resolve.
we have an application we develop which calls home to a server. By default it is configured to use the external ip address and just makes a round trip when used internally (vs at a customer site). This application functioned fine before implementing PFsense, and it still works if you change to the internal dns name as the target manually every time.
I am seeing some odd firewall logs. A few examples below (ip and ports have been changed to protect the innocent)
Dec 29 11:52:30 LAN Source 192.168.0.99:80 Dest 114.129.1.2:594 TCP:PA
Dec 29 11:37:39 Direction=OUT LAN Source 62.232.5.1:547 Dest 192.168.0.99:80 TCP:R
information on logged blocks just comes up with:
@4 block drop out log inet all label "Default deny rule IPv4The PFSense box is the gateway for the server (dedicated with dedicated internet connection)
L3 switch is the gw for end users which go out through another internet connection/fw
users are able to reach the pfsense box. pings in all directions flow.I have tried searching the forum for answers for days,
unblocking private networks,
creating an easyrule and then mimicking it without the IP address tiedowns,
editing rules to pass all tcp flags and sloppy states.
turning on nat reflectionapplication is working externally.
I am setup to pass all lan traffic and I am using multiple virtual IP's on wan.
Why am I seeing any lan traffic blocks at ALL if I left lan wide open? Shouldn't I just be filtering wan???I appreciate you taking the time to read this and any suggestions you might have.
-
The problem is when you access the public IP address (which is port forwarded to the internal server in question) but from a subnet on the inside of pfSense. In theory NAT reflection should make it work.
In practice it is usually easier to do split DNS. If pfSense is doing DNS service for your internal subnets, then add a host override to define the external name to be the internal (private) IP address of the server.
Local clients will then connect direct to the server private IP. Clients out on the big bad internet will get the usual DNS pointing to the public IP.The firewall log entries you see are out-of-state packets - they are remnants of traffic that has come after some previous state has timed out or…