Messages

Hi all,

Those of you that have been around the *Sense world for awhile probably know me. I've been a fan for a number of years, and have a lot of posts on the pf as well as the opnSense forums. Heck, I may even have a few on m0n0wall, since I go back that far on distros of this firewall.

If you're just now reading this, this is an awesome firewall solution and I've found nothing that compares to it in the commercial world. There's a balance of functionality and UI that I've never seen at this level in a commercial product. So what's below is more for the folks that have been running some version of *Sense for a little while and is not representative of the product of a whole.

Ok, disclaimer over. Now to the real topic:

I have somewhere in the neighborhood of 30-50 *Sense installations in production. These span everything from a terrible DSL connection in the middle of nowhere's-ville to a 200 x 200 Mbps redundant fiber connection in a controlled data center environment. I'm seeing this problem across the board, on all installations. That means everything pf 2.3.2 and newer, and I'm guessing everything opnSense 18.1.x and newer. In other words, I'm thinking this is a FreeBSD problem and not a *Sense problem.

Symptom:

The firewall is set up to reboot on a schedule. After the scheduled reboot, the firewall does not respond to anything remotely. ICMP traffic does not respond, packets are not forwarded, rules are not processed. It's as if the firewall is stuck in the default state of "deny all" for all packets.

Resolution A (a bad one):

Go to the console and log in if necessary. Reboot the firewall using the appropriate menu option. Let the firewall reboot. Check again and see if you can access the outside world, and the outside world can access you.

Resolution B (possibly better?)

Run a script that checks to see if the firewall can reach the gateway device (DSL modem, DOCSIS router, fiber router, etc.) and/or a common website (Google DNS, for instance). If it cannot, issue a reboot command. Possible side-effect: This could reboot the firewall in the middle of the day with no warning to your end users.

Anyone else run into this problem? The most common hardware we use are Dell PowerEdge R2{x}0's as firewalls, so its possible it is specific to those, but I believe I've also seen this behavior on the micro-firewalls we have running made by a reputable Amazon reseller ending in "LI". ;-)

DISCLAIMER: If you can't tell, this email has been formatted to avoid getting a nasty letter from that one company that bought one of the *Sense distributions and has been known for sending nasty letters to people trying to help.

I may be seeing the same behavior, but I'm giving it time to find out for sure. However, I'm wondering if this helps at all:

Under VPN >> OpenVPN >> Servers >> RoadWarrior VPN (Edit it) >> Renegotiate Time it says:

"Renegotiate data channel key after n seconds (default=3600).
When using a one time password, be advised that your connection will automatically drop because your password is not valid anymore.
Set to 0 to disable, remember to change your client as well."

Mine was set to 0, so I changed it to be 86400, which is the equivalent of one day. I'm now waiting to see if this "resolves" the problem, ie: how many users will remain connected to the VPN for more than 24 hours? And if they do, isn't it appropriate to ask them for another OTP?

Thanks for the response, Fabian. I'll pursue logstash and report back on my findings!

Hi all,

I haven't seen this here yet, but perhaps I missed it. If so, let me know and I'll see myself out. ;-)

I've recently been exploring the idea that access log data from squid could be piped into MySQL (see here). My thought is NOT that the OpnSense server would host this MySQL data, but rather that I could push that MySQL data to a MySQL server internally for further analysis. All of this comes from the desire of management-types that do not want to read through data, but rather would like to see the data from a 1000 meter view and then tunnel down into the data they want.

For instance, if last week squid allowed 98.5% of traffic and blocked 1.5% of traffic for employees, that's one "1000 meter" view. Then if management wants to drill down into the 1.5% of traffic to see what is being blocked and who is attempting to access that information, they can.

Ultimately, this comes around to being able to ask squid on opnsense to send the log file to MySQL. And the link above seems to indicate that squid is possibly capable of doing so. The question is, has anyone done it, is it possible with OpnSense on the BSD platform (as the link above is for a debian platform), and if the answer to that question is yes, what would it take to get the functionality incorporated into Squid for OpnSense?

An ancillary question that I could see coming about would be a way to point multiple OpnSense servers to a single MySQL database (again, internally, over the VPN tunnel for instance) and the ability to see the multi-site view. Why is the internet in [location] always so slow? Lets see what their browsing patterns are like....

So, how far-fetched is this idea? In the short term I'm considering deploying proxy servers out to each location,  but in the longer term, I'm looking for a way to manage the data in a way that isn't cumbersome.

Hi all,

I've been around the community for a few years now, but I'm a pfSense convert like most of us here. I've used pf/OpnSense for going on 10 years (?) now. So, not exactly a newb, but I generally stay pretty quiet.

I have a small municipality who is running pfSense. I'm in the process of converting all the firewalls over to OpnSense. The local Sheriff's Office IT only uses Cisco, and nothing else. Since we have to interface with them for various agency records, this means they have Cisco appliances in key buildings sitting right next to the pf/OpenSense firewalls, plugged into the same ISP router, and with their own external and internal IP address. This creates two points of entry into the networks instead of one, which makes it doubly difficult for me to take responsibility for keeping the network safe. So, on this last expansion run (for ancillary stations) I suggested that we just set up an IPSec VPN tunnel between the county and the existing pfSense/OpnSense firewalls that are on-site at each location.

You'd think I dropped a bomb on them.

The present (valid) argument for why this is not feasible is that the OpnSense firewall platform is not FIPS 140-2 certified. Looking purely at the technical requirements, I think it'd pass with no problem, but the question is, what does it cost to make a firewall FIPS compliant? Is this something the OpnSense community should consider pursuing? Is HardenedBSD going to make this easier for us, assuming the development of OpnSense eventually gets there?

I can foresee running into this problem with other industries that have a standards-based auditing system of firewalls, examples being PCI, SOX, HIPAA, etc. so it'd be nice to hammer this one out before those come up.

Any/all responses are appreciated.

FYI, +1 on this end for rolling back to show/use Peer Identifier / Group address. Couldn't make it work without it, and then once I ran the rollback patch on 18.1.5, it worked.

This was EXACTLY the fix I needed. Thank you! Please update the documentation with the linked help?

Hi there,

I'm still struggling to implement BiNAT over various IPSec Phase 2 tunnels. Here's how it's handled in pfSense:

Mode: Local Network
Type: LAN Subnet (Mine is 192.168.121.0/24)
Address: [Blank]
NAT/BiNAT Translation Type: Network
NAT/BiNAT Network: 172.16.254.0/24
Remote Network Type: Network
Remote Network Address: 172.16.246.0/24

So, whenever traffic goes out to the 246 network, it should appear to come from 172.16.254.[ip]
Whenever traffic comes in from the 246 network, it should appear to come from 172.16.246.[ip], even though on their end it's likely something like 192.168.1.[ip], and we have BiNAT set up there too.

Lastly (and most importantly) Whenever traffic comes goes out to the 10.0.143.0/24 network, it should appear to come from 192.168.121.0/24 because that is a branch office and it has no BiNAT defined in the Phase 2. There's no chance of a conflict and therefore no need to BiNAT.

If I try the same thing in OPNSense, it looks like this:

Mode: Tunnel IPv4
Description: Customer Name
Local Network Type: Network
Local Network Address: 172.16.246.0/24
Remote Network Type: Network
Remote Network Address: 172.16.254.0/24

Then I create a rule in Firewall >> Nat >> One to One
Interface: IPSec
External IP: 172.16.254.0/24
Internal IP: 192.168.121.0/24
Destination IP: * (Any)

... but this takes over all IPSec traffic going out and makes it appear to come from 172.16.254.0/24 in the firewall logs.

Is there a way to just set BiNAT settings in the Phase 2 settings and be done with it?

[This works, but it negates the documentation I see here]

Hi all!,

Long time monowall/pf/OPNSense user here. I'm a network engineer for a managed service provider in Ohio.

I'm converting firewalls at customers from using pfSense to OPNSense as upgrades are required. I've discovered something through trial and error, but need to know if it's the proper way to be doing things...

For customers, we use BiNAT VPN tunnels extensively. This is because it's incredibly common to run into customers with 192.168.1.0/24 networks or 192.168.0.0/24 networks, and we need to be able to monitor their stuff over an encrypted tunnel from our office. We utilize rules on our side so they can only see the network monitoring server and everything else is blocked. On our side, however, I can see their whole subnet. So it's common for me to have a setup that looks like this:

Customer Side: 192.168.1.0/24 binat to 172.16.212.0/24
Our Side: 192.168.254.0/24 binat to 172.16.254.0/24

So the tunnel on their end is looking for a remote subnet of 172.16.254.0/24, and maintains a local subnet of 192.168.1.0/24 with BiNAT to 172.16.212.0/24.

The tunnel on our end is looking for a remote subnet of 172.16.212.0/24, and maintains a local subnet of 192.168.254.0/24.

On the customer's Firewall >> Rules >> IPSec it looks like IPv4 * * * * * (Allow IPSec Traffic)

On our end in Firewall >> Rules >> IPSec it looks quite different, only allowing customer VPNs to get to one IP address.  :)

So the question became, how do I make this occur in OPNSense? The Phase 1 always establishes with no issue, it's always the Phase 2 that is broken. So, here's what I've tried so far on my Phase 2 Tunnel configuration:

• I tried LocalNet as 192.168.1.0/24, RemoteNet as 172.16.254.0, and Manual SPD as 172.16.212.0/24. No joy.
• I tried LocalNet as 172.16.212.0/24, RemoteNet as 172.16.254.0, and Manual SPD as 192.168.1.0/24. No joy.
• I tried LocalNet as 192.168.1.0/24, RemoteNet as 172.16.254.0, and Manual SPD I left blank. I then tried going to Firewall >> Nat >> One-to-One >> Created a BiNAT that looks like IPSec, External is 172.16.212.0/24, Internal is 192.168.1.0/24, Dest. is Any. This works, but it negates the documentation I see here:
  https://forum.opnsense.org/index.php?topic=989.0
  https://github.com/opnsense/core/issues/369

So, is the issue just that we need an updated tutorial or documentation?

Thanks in advance!