[pfSense] Diagnosing DNS Resolver SERVFAIL issues

[Antonio]

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

[pfSense] Introducing flexibility of traffic routing when VPN is configured

[Antonio]

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

[pfSense] Custom pass entries for Suricata for all rules, for inline mode

[Steve Yates]

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 1.2.3.4 any <> any any (msg:"pass all traffic from/to 1.2.3.4"; 
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

[pfSense] Some upgrades from 2.4.2-1 to 2.4.3-1 failed at reboot

[Odette Nsaka]

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

Re: [pfSense] Bandwidth Mismatch between pfSense and Data Center Provider...

[Chris L]

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

Re: [pfSense] Syntax error in rules.debug for lagg0 (WAN) after upgrade to 2.4.3_1

[Steve Yates]

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 [242]: pass out  route-to ( lagg0 64.79.96.145 ) from  
to !/ tracker 105913 keep state allow-opts label "let out anything from 
firewall host itself"

64.79.96.145 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 64.79.96.145 ) from 64.79.96.149 to !64.79.96.144/29 
tracker 105911 keep state allow-opts label "let out anything from firewall 
host itself"
pass out  route-to ( lagg0 64.79.96.145 ) from 64.79.96.150 to !64.79.96.144/29 
tracker 105912 keep state allow-opts label "let out anything from firewall 
host itself"
pass out  route-to ( lagg0 64.79.96.145 ) 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