I can't get *OFF* my VPN anymore…:-)
-
@Hollander:
then mixes up interfaces and firewall rules, and you end up doing a fresh install for every minor upgrade;
If that were remotely true there would be a massive abandonment of the project, tons of people complaining here, and we'd have a mess with our 500+ active commercial support customers. None of that's the case. Tens of thousands of systems have upgraded via auto-update alone in the past month or so, through 2.1.1, 2.1.2, 2.1.3. We've handled several dozen cases of "I upgraded and now <something>is broken" with support customers. The only such issues that were actually caused by the upgrade were those who didn't upgrade the AutoConfigBackup package before upgrading to 2.1.2 (though we sent out an email to all gold and support subscribers with a "HEADS UP", in addition to mentioning it in the release announcement and elsewhere). One of the pluses of having to do a 2.1.3 is it actually isn't impacted by that ACB bug.
That was a minority of the cases though, as usual, the majority of "upgrade problems" are problems that would have happened just by rebooting the system. "I upgraded and the system isn't booting anymore" turns out to be the hard drive bit the dust, the BIOS no longer sees it at all post-upgrade. A variety of hardware failures that didn't exhibit themselves until a reboot is one of the more common. Dead drives, systems that can no longer get through POST to even attempt booting from anything. Those are most all the scenarios where people are using ages-old hardware, at times literally pulled out of a dumpster. A small number of cases where people loaded up way too much for 256 MB RAM on an ALIX, where they're running with maybe 10 MB free RAM, and are left with a system that can't boot without running out of RAM, causing the dying of random processes that are part of the boot process. Especially with several OpenVPN instances because it uses more RAM during its immediate start up than it does during normal operation. In those cases, the upgrade aborts and it just reboots into the same version, except you have a config that can't necessarily successfully boot because you've overloaded things. A number of other scenarios along those lines, where it's not the upgrade, it's the reboot.</something>
-
@cmb:
Nothing described there appears to be a bug. OpenVPN client will accept pushed routes unless you tell it not to. Most VPN providers push a default route, which will send all your traffic out the VPN. Add a route-nopull to not do that.
Thank you Cmb, and sorry for my rant; I was fed up.
Unfortunately, I fail to understand what you write. If I tell the firewall to send only specific traffic through the VPN-gateway (via the gateway settings at the bottom of the screen), and it doesn't care about that and sends all traffic through that gateway (which is not the default gateway so it can't be caused by that), how can this be 'the system works as designed'?(??).
Everybody who helped me in this forum setting VPN up says the way I did it is the way it should be done, even your handbook says that. Or, to put it otherwise: then what is the use of the gateway-assignment in the firewall rule if the system doesn't care about it in the first place?
As it is, it is not working for me: with a firewall rule to send only one server in my LAN (192.168.2.21) via the OpenVPN-gateway, it ignores that and sends all LAN-clients through the VPN-gateway.
If you say that this is not a bug but a feature, then I'm losing you. Which most likely is my fault, and not yours, I might add. these faults come with my eternal noob status :P
EDIT: I am trying to relate the current experience to your explanation. Which is this:
For the record: in the Firewall LAN rules you have some general rules (DNS, block netbios, etc), and then next we have the specific rule (say rule A) to direct a server on LAN (192.168.2.21) via the PIA gateway. After that, the default LAN-to-any comes (say rule B), which goes via the default gateway (so, normal VDSL, no PIAVPN).
1. IF I put a firewall rule (say rule C) to the very top of the LAN-rules, so before all the other rules, to tell a specific LAN client (192.168.2.41) to go via the default gateway (so basically the same as rule B), it will do that. It will not go via the VPN.
2. IF I remove that rule, the LAN-client is supposed to use the default rule B. But it doesn't do that: it goes via rule A, so via the VPN.
3. Even IF I put the same rule C right after rule A (so I am explicitly telling the LAN-client to use the default gateway and not the VPN), it still goes via the VPN, so it uses the rule A, not the rule C and not the rule B.I am trying to relate this to your 'it works as designed', as it now seems the only way I can get the normal LAN client not to go via the VPN is to put an explicit 'use the default gateway' on the top of the LAN firewall rules. Which is the only place where this works.
Would you mind sharing your thoughts on this?
Thank you very much ;D
-
@cmb:
@Hollander:
then mixes up interfaces and firewall rules, and you end up doing a fresh install for every minor upgrade;
If that were remotely true there would be a massive abandonment of the project, tons of people complaining here, and we'd have a mess with our 500+ active commercial support customers. None of that's the case. Tens of thousands of systems have upgraded via auto-update alone in the past month or so[]
I of course will not debate that, because what you say makes sense. However, I started with 2.0, and not a single upgrade since then (doing every upgrade since then up to 2.1.2) worked for me. Packages installing, deinstalling, reinstalling, deinstalling, and that for hours. And then WAN that suddenly had become LAN, and more of these matters. For that reason I don't upgrade anymore. Every upgrade means a fresh install for me. I don't know why it works for other people but not for me (like said, I am not disputing you), but for 4 or 5 upgrades it didn't work. As you know in science it is not the 99% that is interesting, it is the 1% that doesn't fit the model ;)
_PS About buggy: this morning I had another thing which I consider buggy; my VDSL broke down. As I am awaiting new, better, network cards, I currently have no fail over with my CABLE. So I simply switched the CABLE/VDSL-modem cables, so now the CABLE is in WAN. For that I had to change PPPoE to DHCP in the WAN-interface. The system first nagged me about 'you have to reassign the interfaces'.
Huh, really? For what? For changing a network cable? Huh?
And next refused to set the connection type for this CABLE-WAN connection to DHCP, complaining: 'a DHCP server is active on this interface, disable this first'.
Huh, really? Where? The pfSense DHCP-server runs only on LAN and VLAN, not on WAN.
It may be the supposed design, but you perhaps will agree with me that, for noobs (and perhaps also others) this is confusing to say the least._
-
@cmb:
@Hollander:
(Try to debug, look in firewall logs: rule description: "block unauthorised DNS". Port? 137. Which is a different rule to block netbios..).
Logs strictly have rule numbers. Rule numbers change if you change your ruleset. There is no record of what the rule numbers used to be, so that's the expected behavior since you've changed your rules between when the log happened and when you clicked to see what rule hit it.
If you allow me: this is a most strange design. Because with any one change in the firewall rule set the whole firewall log becomes useless.I have little to no serious knowledge about network security, which is why I declare myself the eternal noob in this area, but it seems, at least so they say, I have 'some experience' in huge ERP-systems (I even have an old badge here that says I am a so called 'platinum architect' (yes, I got to fly business class and the clients paid ;D )), and if the ERP systems I helped implementing for years in my previous career would have a logic like this, none of the multinationals that use this ERP would even remotely consider a global roll out and deployment.
Unless I am misunderstanding you of course, which is not to be ruled out for the eternal noob that I am _;D
EDIT: to explain what I mean, from the area of ERP:
Suppose, in MDM (Master Data Management), I have a Material Master 1 (meaning: a database record for a material, may that be a raw product, a semi-finished product or a finished product). The master has around 400 fields, one of them being 'description'. Now suppose I add a new Material Master 2, and because of this simple act, in the BOM-explosion (BOM = Bill Of Materials), suddenly the description of Material Master 1 has changed to be that of Material Master 2. Our factories would break down, because our factory workers can't seem to get a car tyre assembled into the Ipad they are currently working on ( ;D ).
Does this help clarifying the point I am trying to make?_
-
I agree with you Hollander, the logs should remain in-sync after rule modifications; however the way it is now you just have to review your logs before you make rule changes. Using things like "aliases" as placeholders in rules help as you can edit the alias information without causing the logs to go out of sync.
I believe that 2.2 will have a significant change in how the logs function.
-
This still is a problem :-[ :'(
It happens to appear randomly. Summary:
[b]LAN-rules:
- First rule: send traffic from 192.168.2.47, destination ALIAS_VPN, out via VPN-gateway.
- Second rule: send all other traffic via the default gateway (DSL, failover with cable, so not via VPN-gateway).
So: only a few specific sites should go via the VPN, all others should take the normal, not-VPN-way.
What happens?
Traffic from the 2.47 that should not go via the VPN goes via the VPN randomly. I notice that, since gmail (pop3) is not to go via the VPN, since gmail then complains that log in is not from my normal country and blocks all. I get frequent, yet random, emails that gmail has blocked my access since I appear to come from 'abroad'. So, with pop3 checking every five minutes, at least 2 or three times a day I get these gmail blocks, so at least 2-3 times a day, without me changing anything in pfSense, suddenly traffic is sent over the VPN.Step-2:
So I put an explicit rule in front of all the others, telling pfSense to route all traffic from 2.47 through the VDSL line, so nothing via VPN.Result: everything goes via the VPN.
Could perhaps anybody, an admin/developer, help me debug and solve this? Because this is useless: there is a reason why I have a VPN set up. If the system decides randomly on what it is doing I have no way of knowing if it is actually sending traffic that I do want sent through the VPN will actually go through the VPN.
Please help (peep :-[ )?
Thank you in advance very much,
Bye,
-
Did you add the "route-nopull" I mentioned earlier? Traffic goes out via a VPN for one of two reasons - the routing table tells it to, or the firewall rules are configured as such that policy routing forces the traffic out that way. Traffic that doesn't match a firewall rule specifying the VPN gateway going across the VPN would have to be because of the routing table (or maybe it matches the policy routing rule and you don't realize it).
-
Thank you very much for replying, Sir Cmb ;D
(or maybe it matches the policy routing rule and you don't realize it).
I am most sure that is not the case; the firewall rule uses an alias, and for example gmail.com is not in in that alias.
@cmb:
Did you add the "route-nopull" I mentioned earlier?
Well, I tried, but it doesn't appear to help me. I addition to which I think I get an error:
openvpn[51037]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) ```] This is what I have in the 'advanced options' in the OpenVPN-client config in the GUI:
auth-user-pass /etc/openvpn-password.txt;
remote-cert-tls server;
verb 5;
keepalive 5 30;
route-nopull;The log is rather long, so I have pasted it in a text file and attached it to this post (I replaced my IP with [REMOVED] in that log. I'd be in much debt for help; thank you in advance very much ;D ( :-* ) Bye, [openvpnlog.txt](/public/_imported_attachments_/1/openvpnlog.txt)
-
The "Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])" log is normal when you have route-nopull, that's just OpenVPN telling you it's ignoring the pushed route(s), albeit in a confusing sounding log.
Is there something you can do to replicate the issue? I'm curious what your routes look like under Diag>Routes at the time, and a copy of your /tmp/rules.debug file from when it's not working might be useful as well.
-
2.2.6, still problems.
FW rules, on top of the screen of course:
1. 192.168.2.40 goes to geenstijl.nl -> use gateway PIA VPN.
2. System/advanced: skip rules when gateway is down: checked.
3. Disable PIA VPN: 2.40 happily goes to geenstijl.nl.The opposite is also true: all kinds of sites that are NOT in an alias to catch it via policy routing, simply go via the VPN they should not go through.
route-nopull was added 18 months ago.
It still seems pfsense is randomly deciding whether or not it will send traffic via the VPN; sometimes it sends traffic it shouldn't send, and vice versa.
-
Created new screen shots.
I'm sure it is not a bug, but if somebody can explain to me why the top 1 rule in FW is not followed, I'd be obliged.
-
Have you enabled logging for each of the rules with a meaningful description so you can diagnose?
There can be several reasons why imo.
The route no-pull is not working. The syntax for that command can be variable so try with the space rather than hyphen.
Also whether you are double NATing somehow. I had a replay situation at one point which meant the packets went through the firewall twice with unexpect d results. The logging will diagnose that. My state table was in the thousands also.
Also whether your netmasks are correct. You might intend one host but by /24 masking it you may let the whole subnet through etc. just do an audit of your netmasks for any mismatches.
Finally that you have ipv4/v6 attention and protocols set correctly.
-
I cant be bothered to read a zillion lines of text.
- assign an interface to ovpn if you havent already.
- activate route-no-pull checkbox. If the checkbox is not there due to the ancient release you are running: enter it in adv field.
If 1&2 dont help then post a screenshot of the routing table.
Veel plezier. ;)