I can't get *OFF* my VPN anymore…:-)
-
@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. ;)