Hi, I've been happily using the "Outgoing Network Interfaces" set to my VPN interface to prevent DNS leaks and its been working pretty well until today when all of a sudden it stopped resolving DNS requests. In fact, [fri may25, 03:04 ][user@1:~]nslookup www.google.com Server: 192.168.2.1 Address: 192.168.2.1#53 ** server can't find www.google.com: SERVFAIL 192.168.2.1 is my pfSense box hooked to DSL modem. As soon as I set "Outgoing Network Interfaces" to my WAN, then it all works again. However, this means that although my traffic is vehicle through VPN, the DNS Resolver is routing requests via ISP instead of VPN. I don't understand how all of a sudden the VPN server stopped allowing DNS requests to be passed from my pfSense maching. Does this seem plausible and how do you think I can diagnose this? The is no way i can get ubound to work unless i set "Outgoing Network Interfaces" to WAN. This was not the case until yesteday. Any clues? Thanks -- Respect your privacy and that of others, don't give your data to big corporations. Use alternatives like Signal (https://whispersystems.org/) for your messaging or Diaspora* (https://joindiaspora.com/) for your social networking. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Hi, a while ago I successfully manage to setup a VPN connect on pfSense. I was a great success as it took me a while to get it working. I followed the guide here: https://www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn/#additional. I have a wired network on 192.168.0.0 where I have my desktop and other wired devices. Then i have a wireless network 192.168.1.0 where a access point is connected to the pfSense router. Now, with time, I've realised that its not very flexible in that I'm having to manually disable rules etc. to get things working and then re-activate them to switch usage. I want to make things a but more flexible without losing functionality. In the above guide, under "Additional steps to route WAN through tunnel", where you create the firewall rule to route the traffic from the created alias (192.168.0.0/24) through the VPN tunnel, this rule works well when I want to route traffic from my desktop (on the 192.168.0.0 network) to the internet, whether through the VPN or through normal ISP. However, this is preventing me from pinging my mobile phones on the 192.168.1.0 network. In fact, as soon as I disable the alias rule above, I can ping my mobiles but then I can't browser the internet from my desktop on the 192.168.0.0 network. This is leading me to having to disable/re-enable the rule everytime I have to swith between having to reach my mobile or having to reach the internet from the desktop. This alias is not stopping me from pinging the desktop from my mobile. I guess the tutorial was set up non-complex usage in mind. But how can i make this a but more flexible so that internt traffic can go down the VPN and local traffic between different LANs are not affected? I hope I've explained my problem well enough. Many thanks -- Respect your privacy and that of others, don't give your data to big corporations. Use alternatives like Signal (https://whispersystems.org/) for your messaging or Diaspora* (https://joindiaspora.com/) for your social networking. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
I know Bill (bmeeks) hangs out in the web forums but since they're offline, does anyone know if it is possible to allow an IP for Suricata when it's in Inline mode? I see lots of examples like: pass ip 184.108.40.206 any <> any any (msg:"pass all traffic from/to 220.127.116.11"; sid:10;) ...but I gather that is tied to the specific rule/sid? The use case is it seems to be triggering on our Nagios monitoring of our web servers and I'd like to just whitelist our office IPs rather than trying to manage bunch of rules. (for those unaware, Pass Lists will be removed from Inline mode: https://webcache.googleusercontent.com/search?q=cache:VUgCeE4j3yQJ:https://forum.pfsense.org/index.php%3Ftopic%3D135331.0+=1=en=clnk=us=firefox-b-1-ab https://webcache.googleusercontent.com/search?q=cache:6eT7PljragcJ:https://forum.pfsense.org/index.php%3Ftopic%3D145257.0+=4=en=clnk=us=firefox-b-1 ) Thanks, Steve Yates ITS, Inc. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Hi all, I upgraded some pfSense on APU CPU Type AMD GX-412TC SOC 4 CPUs: 1 package(s) x 4 core(s) AES-NI CPU Crypto: Yes (active) from 2.4.2-1 to 2.4.3-1 The first one via cmd-line (VPN - SSH). It was installed with the default single disk ZFS option on SD, then set up (via GUI) to use / tmp and /var on RAM: zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls) The upgrade seemed to go on regularly, but the system did not came up for many hours. Connected to the serial console, even after a power cicle, it showed (as copied from the console, sorry for the double chars): NNoo //bbtt//kkeerrnneell//kkeerrnneell FFrrBBSSDD//xx8866 bbtt DDeeffaauulltt:: 00::aadd((00,,aa))//bbtt//kkeerrnneell//kkeerrnneell bbtt:: I thought it could be a problem related to /tmp or /var in RAM, but it I guess it wasn't because I reinstalled pfSense 2.4.2-1, reloaded the config I saved just before starting the previous upgrade so /tmp and /var should have been in RAM again. Then I upgraded via SSH (while connected to the serial console to monitor the process). Now the upgrade worked fine. So, seen the problem I had on the first one upgrading via SSH I upgraded some other similar APU from 2.4.2-1 to 2.4.3-1 via GUI. All of them are on SSD, some in UFS, some on ZFS, many of them with /tmp and /var in RAM. All but one (SSD, UFS, /tmp and /var in RAM) upgraded fine. The one that did not upgrade was in the same status and with the same message copied above. Again I reinstalled 2.4.2-1, reloaded the last config, upgraded via GUI and everything worked fine. Did someone have similar issues or have any clue abaout it? /Odette/ ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
On May 23, 2018, at 10:57 AM, Chuck Mariotti
wrote: > > We've run into a data overage situation at a datacenter... We get charged a > premium per GB over 500GB (yes I know, stupid). Their reporting system seems > to indicate significantly less data usages vs pfSense's RRD reporting... > their billing system seems to be indicating overage similar to their > reporting... Uploads seem to be growing significantly. Any idea why the > pfSense box seems to be counting differently than the datacenter's metrics? > We need to track down where this usage is happened, but I know users have > only grown ~5% over that same period of time. > > Here are stats for each month: > > JanuaryFebruary > March April >May (to 23rd) > Datacenter (Upload/Download): 618.95GB/76.01GB > 365.25/47.15GB799.92/79.81GB801.67/105.01GB >581.57/76.26GB > pfSense RRD (Upload/Download):1372.41GiB/148.91GiB > 1388.65/149.60GiB 1697.71/152.24GiB > 1706.53/200.86GiB 1177.95/139.55GiB > > > Any suggestions how or why there is a mismatch? > What version of pfSense? I recall there was an issue with counting double. With the exception of your Feb numbers those are all very close to double. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Finally found https://redmine.pfsense.org/issues/8518 which is this bug (the extra incomplete gateway line). Fix seems to be to delete/comment out three lines in /etc/inc/filter.inc: https://redmine.pfsense.org/projects/pfsense/repository/revisions/c9159949e06cc91f6931bf2326672df7cad706f4/diff/src/etc/inc/filter.inc?utf8=%E2%9C%93=inline A poster on that report says "When I try and add an IPv6 IP Alias VIP the error seems to appear" which would explain why we didn't see it on other 2.4.3_1 updates that have only IPv4 VIPs. I did try changing off the LAGG to just the one interface on WAN and that had the same symptom with the interface in the message. -- Steve Yates ITS, Inc. -Original Message- From: Steve Yates Sent: Wednesday, May 23, 2018 10:34 PM To: 'pfSense Support and Discussion Mailing List'
Subject: Syntax error in rules.debug for lagg0 (WAN) after upgrade to 2.4.3_1 After upgrading our HA routers from 2.4.2_1 to 2.4.3_1, every few minutes they are logging: There were error(s) loading the rules: /tmp/rules.debug:242: syntax error - The line in question reads : pass out route-to ( lagg0 18.104.22.168 ) from to !/ tracker 105913 keep state allow-opts label "let out anything from firewall host itself" 22.214.171.124 is our WAN gateway. We have the WAN configured to use a one-interface LAGG to allow sharing CARP states if we ever use a different router with a different interface name. Searching /tmp/rules.debug for "lagg0" I see three lines at the top of the output: pass out route-to ( lagg0 126.96.36.199 ) from 188.8.131.52 to !184.108.40.206/29 tracker 105911 keep state allow-opts label "let out anything from firewall host itself" pass out route-to ( lagg0 220.127.116.11 ) from 18.104.22.168 to !22.214.171.124/29 tracker 105912 keep state allow-opts label "let out anything from firewall host itself" pass out route-to ( lagg0 126.96.36.199 ) from to !/ tracker 105913 keep state allow-opts label "let out anything from firewall host itself" .149 is the WAN IP, .150 the CARP shared IP. Given the first two are there, I'm not sure what the third is supposed to be? Re-applying the firewall rules does not clear it, though does appear to trigger it (presumably due to the rules reload). Suggestions? Steve Yates ITS, Inc. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold