API calls blocked by pfsense 2.2.1
-
I just installed a brand new pfsense 2.2.1 box this morning. All was good until we discovered that all of our API calls were being blocked. Everything else works fine. We were upgrading from our old 1.2.3 box that blew up and the API calls worked fine there. We are running in transparent bridge mode with the single WAN bridged to the OPT1 interface. The LAN interface is used for the pfsense gui only and is not internet exposed. The WAN has a public IP address and so do all the servers connected to OPT1 (there is no NAT or DHCP). All switch states tables have been flushed and everything has been rebooted.
I found this post of someone else having the exact same issue but there is no resolution posted.
https://forum.pfsense.org/index.php?topic=82241.0
Base on that post I went into System:Advanced:Firewall/NAT and checked the box that says "Disable all packet filtering" and the API problem immediately was resolved. Of course all the firewall filtering stopped too but at least we are working for now.
What did I do wrong here?
Should I downgrade back to 1.2.3?
Thanks
-
What API calls are you using and what are you using your servers for?
-
So when it's blocked, you get something in the firewall log?
-
Did you try disabling scrub?
-
The API calls are made by ColdFusion scripts (java) to http and https sources.
The servers are all Windows 2008 and 2012 just like the other person with this same issue.
I was not able to find anything in the logs but I may be looking in the wrong place. Please tell me where I am to look.
I disabled scrub and re-enabled packet filtering. APIs would not connect. I disabled pf and they connect fine.
-
Running any kind of IDS on the box?
-
Snort is installed but disabled (verified that it is not running). Problem was happening before snort was installed. Should I uninstall it?
-
Please tell me where I am to look.
Look in Status - System Logs - Firewall.
-
I went in the log and searched for the IP of a couple of the APIs.
Attached is our rule info and what the log looks like. I do not understand why this traffic is being blocked.
-
Click on the red X and find out what blocked it.
-
Ok. Here is what it told me:
_JavaScript: The rule that triggered this action is:
@5(1000000103) block drop in log inet all label "Default deny rule IPv4"_
I have searched for this and found a couple of things that said turn on "bypass firewall rules for traffic on the same interface". Unfortunately that did not work either.
Any other ideas?
-
This is a bridge? You are filtering on the bridge, or on the interfaces? Try an allow all rule with log and watch how the traffic flows…
-
Yes it is a transparent bridge (followed the documentation for setup). The filtering rules are on the WAN rule tab. The OPT1 tab has a pass all rule. Adding a pass all rule to the WAN does not resolve the issue.
-
Ok. Here is what it told me:
JavaScript: The rule that triggered this action is:
@5(1000000103) block drop in log inet all label "Default deny rule IPv4"Any other ideas?
No, not really, looks mostly like out-of-state traffic anyway. Do some traffic capture of the Java-produced garbage, perhaps…
-
Here are the non WAN rules and the stuff I changed for the bridge. Does this look correct?
-
pfil_bridge should be 0, pfil_member 1. Assuming the bridge0 isn't assigned, which it didn't appear to be.
-
I changed pfil_bridge to 0.
pfil_member was already on 1.
I saved the change and re-enabled pf.
It did not solve the issue.
-
You didn't show the WAN rules. You put a pass any any any there and it didn't fix the issue? If so, put a floating any any any in and log that.
-
I added a floating rule to pass any as you suggested. I re-enabled packet filtering and tested the APIs. They worked. I hit my IP range with nmap and it shows that pfsense has only the correct ports open so it appears this solved the issue.
First of all thank you very much for the suggestion.
Second can someone explain why I needed this floating pass all rule to make the APIs work?
Does having this floating any rule open up any security risks?
Thanks
