Re: [pfSense] DNS over TLS config for pfSense 2.2.6

[Bryan D.]

On 2018-Apr-05, at 10:47 PM, Dave Warren  wrote:

> Cloudflare has pushed an update, and things seem to be working from here. For 
> those having issues, try again now?

Thanks for the "heads up."  Works for me, also (i.e., on pfSense 2.2.6 
configured as stated in previous posting).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] DNS over TLS config for pfSense 2.2.6

[Bryan D.]

On 2018-Apr-04, at 10:05 PM, Dave Warren  wrote:

> I can also confirm that 9.9.9.9@853 does work here which re-enforces that 
> this is a Cloudflare specific issue.
-

So it looks like the following config works on pfSense 2.2.6's unbound/DNS 
Resolver (so should work with 1.1.1.1 when Cloudflare gets things fixed):
server:
ssl-upstream: yes
ssl-port: 853
forward-zone:
name: "."
forward-addr: 9.9.9.9@853

Thanks!

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] DNS over TLS config for pfSense 2.2.6

[Bryan D .]

Re: https://www.netgate.com/blog/dns-over-tls-with-pfsense.html
---
Applying the suggested "Custom Options" to the Unbound/DNS Resolver 
configuration in pfSense 2.2.6 does not work, with logs indicating that 
"forward-ssl-upstream" is invalid.

I tried various incantations using "server:ssl-upstream: yes" with and 
without "ssl-port: 853" and, although the unbound service would then run, a 
DNS/host query always indicated that no hosts were found.

Does anyone know a configuration that will work with pfSense 2.2.6?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] looking for perfect pfsense box for home?

[Bryan D.]

On 2016-Aug-21, at 5:50 AM, Paul Mather  wrote:

> Even on that page it's incorrect to say it "only" offers the XG-2758.  That's 
> the only one they show in the main table on that page ...

There's likely good science behind the fact that nearly all e-stores will 
present (often overwhelming) detail, by default, along with various filters to 
narrow down the products of interest.

I've also experienced the "you have to make an effort to find it" aspect of the 
pfSense store pages.  Not ideal.  Sales will be lost, as this incident 
demonstrates.

Blaming a would-be customer for not seeing/finding something on a 
catalog/store/marketing page is probably not a good strategy as it won't help 
sales.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] pfBlockerNG: US IPv6 range size

[Bryan D.]

On 2016-Aug-16, at 8:47 AM, Gé Weijers  wrote:

> Hi,
> 
> Trying to define a pfBlockerNG IPv6 alias for the US. It seems that the
> GeoIP database has over a million entries, which causes a crash
> 
> Any idea why the US ranges are this humongous?
> 

I use pfBlockerNG and various other blocking lists loaded as URL Table Aliases. 
 I found (back with 2.1.x?) that the "Firewall Maximum Table Entries" under 
"System -> Advanced -> Firewall/NAT" tab needs to be set much higher than the 
number of entries you actually have (e.g., try at least double).

Unless you're very tight on memory, it's safer to overdo it.  E.G., in addition 
to enabling some (maybe 40%?) of the countries in pfBlockerNG, I also have over 
a half million other entries and use a setting of 4M (it was failing at 3.5M 
IIRC).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Route Issue over Ipsec

[Bryan D.]

> Good day,
> 
> I have an issue routing related..
> 
> I found that page:
> https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP%2C_use_syslog%2C_NTP%2C_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F
> 
> It represent exactly what I'm having as issue..
> 
> I did exactly that.. but, as soon I do it, I get the following:
> 

On 2016-Aug-06, at 8:28 AM, Francois Roussy  wrote:

Don't know about Android issues, but "5. Routing OpenVPN through IPSec VPN on 
pfSense" on https://www.derman.com/blogs/IPSec-VPN-Firewall-Setup explains how 
we get routing across multiple site-to-site IPsec tunnels.  This seems to work 
for LAN or VPN client connections to VPN-remote LANs via tcp/udp (subject to 
firewall rules) -- i.e., a mobile VPN client (IPsec or OpenVPN) can access LANs 
connected to pfSense via other IPsec VPN tunnels, including services such as 
SNMP on local and remote pfSense boxes ... which is what I guessed you were 
attempting to do.  Don't know whether there's an easier way to accomplish it.

The static route strategy used to work for us in 1.x versions of pfSense, but I 
couldn't get it to work with 2.x so I had assumed it was no longer applicable.  
If that's actually true, then someone should update the doc page.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] How to determine supported packages without installing

[Bryan D.]

On 2016-Jun-17, at 4:03 PM, Steve Yates  wrote:

> I suspect package compatibility is not maintained on per-pfSense-version 
> basis. Meaning, packages worked on 2.x up until the package changes on 2.3, 
> and probably will work on into the future until the next breaking change.
> 
> https://doc.pfsense.org/index.php/Upgrade_Guide#pfSense_2.3_Upgrade_Guide has 
> text:
> See Package Port List for a list of packages currently available on 2.3.
> Links to -> https://doc.pfsense.org/index.php/Package_Port_List
> 
> Also, from the blog entry on the 2.3.1 release:
> https://doc.pfsense.org/index.php/2.3_Removed_Packages

Thanks.  The "port list" page doesn't agree with the list supplied by compdoc's 
response, which appeared to be from a running and current pfSense.  E.G., nut 
(the one that's a "must" for us) isn't listed

Since this is an item that's critical to many pfSense users, I have submitted a 
feature request (https://redmine.pfsense.org/issues/6500).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] How to determine supported packages without installing

[Bryan D.]

On 2016-Jun-17, at 2:35 PM, compdoc  wrote:
> I think this is complete:
> 

Thanks.  Looks like I can proceed with an update to 2.3.

Regardless, I still think there should be a way to authoritatively determine 
this info via the pfSense web site -- ideally, for all releases, minimally for 
the current release.  Perhaps the generation of such a page could be added to 
the build/release tools?  Alternatively, porting pfSense's packages pages to 
run on the pfSense site could provide the current-release info.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] How to determine supported packages without installing

[Bryan D.]

On 2016-Jun-17, at 2:02 PM, Peder Rovelstad  wrote:
> This help?  https://forum.pfsense.org/index.php?topic=8640.0

Thanks, but I don't see anything there that tells me what the current packages 
are for pfSense 2.3.1 Update 5 (i.e., without having to first install pfSense 
2.3.1 Update 5).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] How to determine supported packages without installing

[Bryan D .]

How does one determine the currently supported packages for the current 
released version of pfSense without installing pfSense, first.

I did find https://doc.pfsense.org/index.php/Features_List but, since there's 
no stated pfSense version associated with the page and since I've found it to 
be inaccurate in the past, I wouldn't trust it.

I also found https://www.pfsense.org/get-support/supported-packages.html 
(though it's "breadcrumb" shows it as being "Home | Support | Supported 
Packages", it's not linked on https://www.pfsense.org/get-support/).  I suspect 
this may be the current one but, again, there's no associated pfSense version 
stated so ... ???

In my case, there's one package I require to be supported before we can update 
to 2.3, so this information is a pre-requisite to updating.

BTW, a site-search capability would be nice, on the pfSense home page.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Unbound connections: excessive???

[Bryan D.]

On pfSense 2.2.6, I switched from dnsmasq to unbound.

Resolver/unbound is configured for DNSSEC (i.e., no forwarding) and has about 
150 overrides to function as our internal/split DNS (with 5 domain overrides 
for internal/private-address reverse lookups).  The "Network Interfaces" 
setting has only the LANs selected and the "Outgoing Interfaces" setting has 
only the WAN interface selected. There are no DNS servers configured via 
"General Setup".  With this setup, I understand that unbound is using multiple 
root servers instead of a small number of caching servers.

All internal systems are configured to use only pfSense as the DNS.  DNS 
resolution works fine.

With dnsmasq, the number of filter states was typically around 125 but with 
unbound, it's now typically around 450 where nearly all the states are 
(pfSense's) port 53/DNS connections.  In addition, the number of states shown 
via the 1-day RRD graph shows an overall escalation from about 200 filter 
states to over 600 filter states.

QUESTIONs:
---
Is it normal to have this kind of increase in the number of UDP DNS-port states 
when moving to unbound with this kind of configuration?

Is it normal to have the number of UDP DNS-port states continuously escalate 
and triple over a 1-day period?

Can anyone suggest something I may have configured incorrectly?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] IPv6 cross-LAN access problem to virtualized host

[Bryan D .]

I'm in the process of enabling IPv6 on a working IPv4 3-LAN, 2-WAN setup using 
pfSense 2.2.6 (I'm also in the process of testing 3.0 and did a cursory test 
and got the same results with our 3.0 test setup).  We're getting IPv6 via a 
Hurricane Electric tunnel.

There are 3 LANs each with a /24 IPv4 and a /64 IPv6 subnet (the /64's being 
from the /48 allocated from HE).  Currently, incoming IPv6 WAN and WAN_IPv6 
access is blocked for all IPv6 except that ICMP types (other than redirect) are 
allowed.  Rules exist allowing unrestricted IPv6 access across all 3 LANs.

I have pfSense configured for DHCP6 on all 3 LANs and RA (on all 3 LANs) is set 
to "Assisted" and (maybe unnecessarily?) "RA Subnet(s)" is set to all 3 of the 
/64 subnets.

Each of the 3 LANs is also it's own VLAN.  There are 3x HP 1810 v2 switches 
across the network.

One of the hosts, the problematic one (and, of course, the only one for which 
we actually want IPv6), is a virtualized OS X 10.8.5 running under VMware 
Fusion 7.1.2 (also on OS X 10.8.5).  The VM host system has 2 VLANs and the VM 
guest has 2 NICs, one bridged to each of the VM host system's VLANs.

Multiple systems on the network, including the "problem" virtualized host, have 
multi-homed IPv4 and (of course) multi-homed IPv6 interfaces.  For simplicity, 
I've manually set the IPv6 addresses and am using only them for testing.

Everything works wonderfully, except that ...

I'm having a problem accessing the IPv6 IPs on the virtualized/guest system's 
interface that's bridged to VLAN3 of the VM host.  Accessing IPv6 and IPv4 
addresses on VLAN1 and VLAN2 works fine.  Accessing IPv4 addresses on VLAN3 
works fine.  "Sometimes" (see below) one of the 2 manually assigned IPv6 
addresses on VLAN3 can be accessed.

[Because of what (at least "sometimes") works, I conclude that neither pfSense 
setup nor a local host firewall is the problem.]

Here's the symptoms:

- boot the problem/virtualized host then, on another system (C) on VLAN1, run 
ping6 against both of the 2 IPv6 addresses on (the interface that's bridged to 
the virtualized host's) VLAN3 and I get "...from  -> 
: Destination Host Unreachable" (addresses are 
config'd and up, according to ifconfig but they're not listed in pfSense's NDP 
table, so this makes [pf]sense).

- on the virtualized/problem host, run ping6 against the other system C, and 
it's OK

- now, again run (the same) ping6 commands from the other system (C) on VLAN1 
against both of the 2 IPv6 addresses on the virtualized host's VLAN3 and it 
works against the first IPv6 listed via ifconfig, but not the second

[I'm assuming that the ping6 run from the virtualized/problem host caused 
pfSense to acquire the one IPv6 IP and that's why it's now accessible -- 
indeed, that 1 of the 2 VLAN3 IPv6 addresses is now in pfSense's NDP table.]

- run ping6 from the VM host system against both of the 2 IPv6 addresses on the 
(VM guest) virtualized host's VLAN3 and both work

[I'm assuming, due to the bridging, that local neighbor discovery works from 
the VM host to its VM guest.  pfSense does not acquire the additional IPv6 
address from VLAN3.]

Tests run from other hosts show results that are consistent with the above 
tests.  So, with 1 exception, everything works and is consistent with what's 
shown in pfSense's and various host's routing tables and via ifconfig.

The failure is that neither of the 2 IPv6 addresses (nor the auto-allocated 
private IPv6 address) from the interface (on the virtualized host) that's 
bridged to the VLAN3 interface are learned/acquired by pfSense unless a ping6 
is run from the virtualized host and then only the first ifconfig-listed 
manually assigned IPv6 address is acquired by pfSense.  As such, pfSense 
considers the IP(s) unreachable.

I'm guessing that there's an issue where OS X is either not reporting the 2nd 
interface (i.e., second in that the VLAN1-linked interface is ordered first in 
the network configuration) or that the bridging is interfering with that 
communication.

I'm assuming that pfSense is "asking" hosts to report via each RA-config'd 
subnet every "now 'n then" and, as such, VLAN3 is receiving such queries.  
(Hmmm, as I write this, maybe this is another thing to look at.)

QUESTIONS:

- has anyone experienced a problem anything like this and, if so, what were you 
able to do about it?

- what's the best way to go about confirming that the virtualized host is 
receiving whatever queries RA is sending out on VLAN3 (assuming that's what's 
happening)?  I do have packet-capture capability on the VM host and the 
virtualized/problematic host ... but is there anything simpler?

- does anyone have any ideas on how I might solve this issue and/or learn more 
about exactly what's happening?

My next attempt will be to configure rtadvd to run on the virtualized/problem 
host (with rltime 0) in an effort to get it to tell pfSense that the second 
interface is present ... but, from what I see in the man page, 

Re: [pfSense] Aggregated WAN traffic

[Bryan D.]

On 2016-May-10, at 10:14 AM, WebDawg  wrote:

> Usually the only thing that you
> can do in this situation is put your connection at its lowest setting
> and control the connection from there.  The problem with this is that
> the connection will always be this lowest speed.

FWIW, our connection is also somewhat "variable" (i.e., our ISP often 
misconfigs their QoS at a higher speed when doing updates and it stays that way 
'till there's an issue and a support person shuts it back down!).

I've config'd pfSense's Traffic Shaper to use FairQ where, according to various 
bits of documentation I've been able to find, uses the bandwidth settings for 
limiting only when saturated and, otherwise, allows the limits to be exceeded.  
As far as I can tell, though I've not done extensive testing, this is the way 
it's working.  Specifically, when our link is misconfig'd for a higher rate, we 
get the higher rate without being stuck at our lower/config'd limit (and 
without any shaping effect unless we saturate that limit, which doesn't seem to 
occur).

Though we don't have a particularly busy network (biggest stressors are 
downloads and 2 concurrent UHD Netflix streams), I've actually been quite 
pleased with the FairQ setting.  We've been using it for at least a couple of 
years, IIRC.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] client VPN on IOS

[Bryan D.]

On 2015-Sep-15, at 6:18 AM, Ray Bagby  wrote:

> Greetings,
> 
>Anyone have any luck connecting iphone via VPN?
> 

You can also see:

http://www.derman.com/blogs/Setting-Up-iOS-OnDemand-VPN

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Routing some trafic throught OpenVPN

[Bryan D.]

On 2015-Sep-15, at 11:39 PM, Andrej Ferčič [PCklinika]  
wrote:

> Hello!
> 
> I am sure that this issue has been already discussed, but I can not find any 
> arhive. So, please give me some directions where to search or any link to 
> thread containig the following:
> 
> 1. Is there any routing throught IPSec VPN possible? (IpSec is solved in 
> kernel as I know)
> 2. How to use OpenVPN to route a specific trafic throught VPN? Let me explain 
> what I want to solve:

The following may also help -- this is the approach I use (along with some 
additional routing rules) to enable access of various systems from one site to 
another both through IPsec VPNs and OpenVPN VPNs ... though the blog is in 
reference to pfSense 2.1, we're now on 2.2.2 with the same setup but using Key 
Exchange v2 and a server-base pinger to keep IPsec connected [this is a known 
issue, search the list postings]):

http://www.derman.com/blogs/IPSec-VPN-Firewall-Setup#RouteOpenVPNthruIPsec

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

[Bryan D.]

On 2015-Sep-04, at 1:18 PM, David Hatch  wrote:

> We are having all the same symptoms above. All of our firewalls are 
> running 2.2.4. Everything that has 2 phase 2 entries is on IKE v2. ...
> 
> Has anyone figured this out? ... nothing I can do will fix it short of pining 
> from 
> a non-pfsense box inside the LAN to a remote location. Doing this 
> constantly will keep the connection solid, but that's about it. Any help 
> would be appreciated. Thanks.

If you search the archives for the subject
2.2.1 Site-to-Site IPsec VPN Connection Instability
you'll find this is an issue that's been experienced by others.

Your "ping via an external system" workaround is what works (code in one of the 
posted emails).

On 2015-04-04 I provided Chris Buechler some logs he requested and on 
2015-04-07 he responded with
---
thanks, that should help narrow things down. I don't see anything
obvious at a glance, will more closely correlate timestamps and across
logs when I have time at some point this week.
---
That was the last I heard.

I'm still on v2.2.2 and the issue still exists.  From what you're saying, 
sounds like it's still in 2.2.4.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] NTP failure in 2.2.1?

[Bryan D .]

On 2015-Apr-11, at 12:51 AM, Fabian Wenk fab...@wenks.ch wrote:

 I had a similar problem, but already when switching from 2.1.x to 2.2. I got 
 it working again with not selecting any interface(s) in the NTP Server 
 Configuration.

I've created a bug report (https://redmine.pfsense.org/issues/4604) with an 
attached (too big for list) PDF of screenshots that show the following:

- 2 time-server entries: time.apple.com and another pfSense box (in that order)

- select both WAN and LAN interface OR select neither interface:
 + other pfSense box is always status Unreach/Pending
 + time.apple.com works

- select only LAN interface:
 + other pfSense box works
 + time.apple.com is always status Unreach/Pending

- select only WAN interface:
 + other pfSense box is always status Unreach/Pending
 + time.apple.com works

I didn't capture the screenshots, but if you reverse the order of the 2 
time-server entries, it also reverses the working vs. Unreach/Pending status, 
given the same interface selection(s).

I have a multi-LAN, multi-WAN config with only the LAN interfaces selected and 
a single time.apple.com time-server entry, and that works fine.

Another simple LAN/WAN box also has only the LAN interface selected and a 
single time.apple.com time-server entry, and that works fine -- but on that 
system, the LAN interface appears first in the list ... so the bug appears to 
be associated with the order of the selected entries in the interfaces list.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

[Bryan D.]

On 2015-Mar-23, at 7:34 AM, Christopher CUSE cc...@ccuse.com wrote:
 just got dropped again -- fourth time in last few hours -- something is 
 definitely wrong.
 
 upgraded all my pfsenses to 2.2.1 over the weekend.

For me, the VPN drops in the absence of end-to-end traffic ... within 
minutes.  The fact that both ends are config'd to ping and do DPD seems to be 
of no consequence.  Our site-to-site VPNs have multiple P2s.  As long as a 
connection exists, (in my limited testing) activating a new P2 seems to be 
v2.1.5-reliable.

I set up a script (running on one of our severs) that pings and the connection 
has been up (with virtually no other traffic, because it's pre-production) for 
about 1.5 days.  It dies within minutes without the pinging.  The script did 
not work when run on the pfSense box, itself (though I really haven't thought 
it through and there could be a perfectly good reason why it wouldn't).


For anyone who's interested, here's the (simple) script:
---
#!/bin/sh
#set -x  ## Uncomment to get a trace

# keep IPsec VPN tunnel(s) connected

#---
# Run this script every minute via the following /etc/crontab entry
# (minus the first comment character):
#*/1  *  *  *  *  admin /usr/local/bin/keepAliveIPsec.sh   ## keep IPsec VPNs 
connected

# The space-separated list of hosts (IP or FQDN) that will be ping'd
HOSTS_TO_PING='172.24.24.1 172.24.28.1'

# Set the maximum number of seconds that a ping will wait for a response
PING_TIMEOUT='1'

# Set the interval, in seconds, between ping attempts to each group of hosts
PING_INTERVAL='3'

# NOTE that the total interval between pings for each host will be the
# PING_INTERVAL plus the sum of the response times for each host being ping'd --
# i.e., where the maximum response time is the PING_TIMEOUT and the minimum is
# the successful ping-response time (for each host being ping'd)
#---

# Don't run if a keepAliveIPsec.sh process is already running
PROCS=`/bin/ps -ax -o pid,command`
OTHER_KEEPALIVE_PROCS=`\
   echo $PROCS | /usr/bin/sed -e '/[ \t\/]keepAliveIPsec.sh/!d' \
-e '/^[ \t]*'$$'[ \t]/d'`
if test $OTHER_KEEPALIVE_PROCS != 
then
   #echo 'keepAliveIPsec.sh already running'  # uncomment for testing
   exit 1
fi

# Ping the required hosts, forever
while true
do
   for HOST in $HOSTS_TO_PING
   do
  #/sbin/ping -c 1 -t $PING_TIMEOUT  $HOST  # uncomment for testing
  /sbin/ping -c 1 -t $PING_TIMEOUT  $HOST \
 21 /dev/null  # comment out for testing
   done

   #echo 'sleeping'  # uncomment for testing
   sleep $PING_INTERVAL
done

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

[Bryan D.]

FWIW, since my original report, I've noticed some other things:

- since it's not yet deployed, the v2.2.1 (at both ends) site-to-site IPsec 
VPN has only 1 laptop and 1 wireless access point on the LAN and virtually 
nothing else happening on the WAN (it's tied to a cable modem)

- the condition, when I did the original report, was that the laptop was 
sleeping -- it's a Mac with network wake-up configured and, in that mode, they 
constantly bring the port up 'n down (hundreds of times per day, each, 
according to switches at this office)

- I needed to make some changes to that laptop so I had someone bring it over 
here ... and that significantly changed the VPN up-ness behavior:

  + now the VPN is _much_ more likely to be up when I attempt to use it (i.e., 
with no LAN-to-LAN non-pfSense traffic, assuming there is some generated by the 
VPN mechanisms, themselves), but ... wait for it ...

  + if I ping the pfSense at the other end and the VPN connection _is_ alive, 
it'll stay alive as long as I continue the once-a-second pinging (from a 
non-pfSense system on the LAN) ...

  + however, if I kill the ping, wait 2 or 3 minutes then ping it again, it'll 
be down ... i.e., the pinging activity seems to stimulate a connection failure 
once the pinging stops (this seems to be a consistent behavior) ...

  + or maybe what I'm seeing is the norm -- i.e., that, as soon as there's a 
lull in Lan-to-Lan traffic for a short time, the connection drops (even though 
the config includes DPD and ping'd host at each end)

e.g.:
[surprise, it's up]
__
/Users/admin  (2015-03-23 @ 15:26:05)
root # ping 172.16.22.1
PING 172.16.22.1 (172.16.22.1): 56 data bytes
64 bytes from 172.16.22.1: icmp_seq=0 ttl=63 time=26.280 ms
64 bytes from 172.16.22.1: icmp_seq=1 ttl=63 time=17.740 ms
64 bytes from 172.16.22.1: icmp_seq=2 ttl=63 time=18.134 ms
^C
--- 172.16.22.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.740/20.718/26.280/3.936 ms


[now wait about 2.5 minutes ... and it's down]
__
/Users/admin  (2015-03-23 @ 15:26:12)
root # ping 172.16.22.1
PING 172.16.22.1 (172.16.22.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
... snip'd
Request timeout for icmp_seq 95
Request timeout for icmp_seq 96
Request timeout for icmp_seq 97
64 bytes from 172.16.22.1: icmp_seq=98 ttl=63 time=15.365 ms
64 bytes from 172.16.22.1: icmp_seq=99 ttl=63 time=14.927 ms
64 bytes from 172.16.22.1: icmp_seq=100 ttl=63 time=13.905 ms
64 bytes from 172.16.22.1: icmp_seq=101 ttl=63 time=15.105 ms
64 bytes from 172.16.22.1: icmp_seq=102 ttl=63 time=17.298 ms
64 bytes from 172.16.22.1: icmp_seq=103 ttl=63 time=18.674 ms
64 bytes from 172.16.22.1: icmp_seq=104 ttl=63 time=16.015 ms
64 bytes from 172.16.22.1: icmp_seq=105 ttl=63 time=15.246 ms
64 bytes from 172.16.22.1: icmp_seq=106 ttl=63 time=15.009 ms
64 bytes from 172.16.22.1: icmp_seq=107 ttl=63 time=15.953 ms
64 bytes from 172.16.22.1: icmp_seq=108 ttl=63 time=17.085 ms
64 bytes from 172.16.22.1: icmp_seq=109 ttl=63 time=21.631 ms
64 bytes from 172.16.22.1: icmp_seq=110 ttl=63 time=16.873 ms
64 bytes from 172.16.22.1: icmp_seq=111 ttl=63 time=16.639 ms
64 bytes from 172.16.22.1: icmp_seq=112 ttl=63 time=15.385 ms
^C
--- 172.16.22.1 ping statistics ---
113 packets transmitted, 15 packets received, 86.7% packet loss
round-trip min/avg/max/stddev = 13.905/16.341/21.631/1.823 ms

__
/Users/admin  (2015-03-23 @ 15:30:21)
root # 

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

[Bryan D.]

On 2015-Mar-23, at 5:24 PM, Chris Buechler c...@pfsense.com wrote:

 There's nothing to go on to offer any worthwhile suggestions. IPsec
 logs best place to start.


If you can be more specific, I'll try to help.  Sorry, but I don't have enough 
background with IPsec to ferret things out on my own.  I did try setting both 
Networking and IPsec Traffic (in Advanced Settings) to Diag then to Raw, 
but saw no additional IPsec logging after pressing the Restart IPsec service 
button on that page.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

[Bryan D.]

We've had a pfSense-to-pfSense always on IPsec VPN connecting 2 offices since 
2008 (pfSense 1.2 IIRC) and it's:
- been ultra reliable (if VPN is down, suspect ISP issue or pfSense box failure)
- it's been quick to connect (about 1 second, almost unnoticeable)
- it's worked across numerous upgrades without issue (nice!)

Beginning with pfSense v2, we added multiple P2s at each end (still same 
reliability, etc.).

One of the offices has had its hardware updated and its pfSense updated to 2.2 
then 2.2.1 (after testing to see whether we seemed to be affected by the 
multiple P2 issue noted in the upgrade page -- we're OK on that one).  This 
connection has continued to work with the same characteristics as before.  The 
2.2.1 system is 64-bit and the other end is v2.1.5 32-bit

We recently added a second site-to-site IPsec VPN, essentially the same as the 
existing one except both sides are pfSense v2.2.1 (but other end is 32-bit) and 
stronger algorithms are being used and P1 is set to v2 (supposedly avoiding any 
multiple P2 issues).

The new pfSense (v2.2.1 at both ends) always on (not!) IPsec VPN is:
- v-e-r-y  s-l-o-w  to connect: e.g. pinging when connection is down yields: 
once a connection after 12 seconds, once a connection after 22 seconds and 
dozens of connections after  2.25 minutes
- completely unable to stay connected: both sides have DPD enabled (5 sec./3 
retries) and both sides can be initiators and both sides have 1 P2 set to ping 
the pfSense at the other end
- pressing the connect button on pfSense's IPsec status page yields an 
instant connection but there won't be any P2 traffic coming back for a while, 
which seems to consistently be the connection-delay issue

If one of the ends has regular (almost constant) traffic, the VPN stays 
connected.  In testing, I've had one non-pfSense system pinging the pfSense at 
the other end and the VPN stays connected.

If VPN traffic pauses for a short time (ten minutes?), the connection is 
dropped.  While that is not what's expected, given the config, it wouldn't be 
bad _if_ the connection was quickly re-established with traffic, but it's not.

I'm providing this information because of the discussions about issues with 
multiple P2s and the idea that they're solved by using v2 P1 at both ends.  
It's quite possible that:
- there are issues with multiple P2s even with v2 P1
- the DPD stuff isn't working
- the P2 automatically ping host stuff isn't working ... but pinging a host 
via a non-pfSense system does keep the connection alive

I'm willing to run some tests if someone wants to tell me what they want done.  
For about a week, the new v2.2.1 site-to-site VPN won't really be used, I can 
do almost anything that doesn't cause the other side to go dead (or I'd need to 
make a trip to the other site and that may not happen very quickly).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] How to troubleshoot

[Bryan D .]

I have a v2.2 64-bit config running on a Core2 Duo system.  The config uses a 
number of aliases (including aliases that include other aliases, etc.).  Rules 
are based upon the aliases (du-oh!).

PROBLEM: if I change the name of 1 of the IP aliases, the name of the 
corresponding table doesn't change ... and, if I reboot, there's a complete 
failure in that NO tables get created (should be 100ish tables).

Reload the config without the change and all is OK.

Compare the config...xml files and there's only the expected changes (i.e., no 
structure corruption, only the name and change-management entries change).

The only error message I've seen is one that indicates something like 
ipsec_starter ... routing con (1000) failed and that doesn't appear to be 
consistent.  I've duplicated this failure on a second identical system, so it's 
unlikely to be hardware-related corruption.

None of the alias names are over 30 characters in length and the change that 
breaks things doesn't create a name that's unusual or as long as many others 
(it's simply adding On within the name).

I tried to create a minimal config that would fail in a similar way, but the 
same kind of thing no longer fails when other aliases/rules/whatever are not 
present.  Mr. Google hasn't helped me find anything similar that's been 
discussed (but I just may not have asked Mr. G. correctly).

I can and have made lots of changes to other aliases without issues, including 
additions and other name changes so it shouldn't be any size-limit boundary.

I have also seen some flakey behavior with the tables generated from some of 
the mixed aliases, where the table's reported content (via the GUI) will 
change as other alias name/content changes are made, but I haven't identified a 
pattern to this flakiness

REQUEST: can anyone suggest:

- ways I can troubleshoot this

- anything I should be looking for
  + are there some unstated/unchecked limits/rules w.r.t. aliases
  + can one not freely create aliases that include other aliases
  + can aliases of type hosts not include aliases of networks type

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Follow-Up -- VIPs : CARP vs IP Alias

[Bryan D.]

So switching the CARP VIPs to IP Alias VIPs, in my config, does work (as I had 
originally expected by the all about VIPs WiKi page) -- it just takes an hour 
or so (in our case) for the up-stream equipment to cache in on those changes 
... as was suggested by a couple of responders.

I've sent the WiKi admin some text to be added under the heading Implications 
(or whatever they may want to title it), since some of the discussion points 
are likely to be useful to others.

soapbox
BTW, this is a practice I'd encourage others to follow as there's often lots of 
good information that steams by in this mailing list and is posted to the 
forums.  While it is possible to find the information, if you know the correct 
search terms, it's also often the case that some of the material should be 
organized and added to the WiKi documentation.

Depending upon your writing apptitude, this will often only take minutes to 
tens of minutes.  I look at this as a small way to contribute and to pay back 
for the effort others have spent in helping.  If we supply HTML-formatted 
additions, most of the time the WiKi admin should only have to do a quick 
read-through before adding the material ... which means that it's likely to get 
done.
soapbox/

Thanks, again, to all who participated.


On 2015-Mar-09, at 6:57 AM, Jim Pingle li...@pingle.org wrote:

 On 03/08/2015 06:50 PM, Bryan D. wrote:
 My interpretation of the nice chart and notes on
 https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses
 leads me to believe that I can switch the CARP VIPs to be IP Alias VIPs.  
 However, when I do that, the 2 servers for the 2 domains tied to the VIPs 
 are no longer accessible from the Internet (but IIRC, the mobile VPNs still 
 work).
 
 Can anyone suggest what it is that I don't understand (well, limited to this 
 behavior, at least)?
 
 As has been hinted at elsewhere in the thread, your problem is likely
 layer 2-related.
 
 CARP VIPs get their own unique MAC address. Proxy ARP and IP Alias VIP
 MAc addresses are shared with the NIC itself.
 
 Changing from CARP to Proxy ARP or IP Alias would cause the MAC address
 of the VIP to change, which may require clearing the ARP cache on the
 modem/upstream router/etc.
 
 Another possibility is that your upstream requires each additional IP
 address to have a unique MAC address. We have seen this with some ISPs /
 certain modems and it's a bit of a pain. CARP works around it because
 each VIP on a different VHID has a unique MAC address, where IP alias
 and Proxy ARP VIPs all have the same MAC address.
 
 So there isn't a clear answer here. Likely, it would be OK to use Proxy
 ARP, but you'll need to reboot the modem or upstream router. If that
 still fails and CARP works, then your ISP or upstream equipment must be
 expecting each IP to have a unique MAC address.
 
 Jim

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-09, at 3:34 AM, Matthias May matth...@may.nu wrote:
 A CARP address has it's own MAC. The IP alias shares the MAC of it's parent 
 interface.
 If you change this while running, your upstream routers/switches will have 
 the wrong MAC address for your IP cached.
 Sending a GARP might help with this.
 Or simply wait for the caches to expire. (This can take a long time)
...AND...
On 2015-Mar-09, at 3:23 AM, Brian Candler b.cand...@pobox.com wrote:
 As long as all these NAT rules are attached to WAN interface, and your VIP 
 is also attached to WAN interface, I can't see why it wouldn't work.  As 
 others have said - changing the type while the firewall is running might 
 break things. Possibly deleting it and then re-adding it would be better, but 
 that's only a guess. If minimising downtime is important then simulate the 
 configuration in a virtual environment first.

Thanks.  This makes sense and likely confirms what I'd expected ... minus some 
of the details.

I'll try changing the VIP for the less critical IP at a low-traffic time and 
also try rebooting the router after the change.  I'm betting it's just didn't 
wait long 'nuff ... these explanations and the other responses have helped in 
the understanding.

Thanks, it's appreciated.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-08, at 3:53 PM, Espen Johansen pfse...@gmail.com wrote:

 I beleive the key to this is proxy arp.
 
 Brgds, Espen
 8. mars 2015 23:50 skrev Bryan D. pfse...@derman.com:
 
 While we're on the topic, I have a functioning v2.2 setup that uses a /29
 set of static IPs:
 - 1 IP is the gateway address and 5 IPs are usable (quite common, I
 believe)
 - one of the usable IPs is assigned to the WAN interface
 - the other 4 usable IPs are assigned to VIPs
 - the WAN IP and VIPs have various port-forward and NAT rules associated
 with them
 - the WAN IP and 2 of the VIPs serve 3 different domains
  (e.g., web, email, VPN -- servers are behind the firewall on isolated
 LAN)
 - one of the other VIPs is used by mobile VPNs (IPsec and OpenVPN)
 
 All this works nicely ... as long as the VIPs are CARP VIPs.  However,
 since I'm not using any fail-over/redundancy, I don't think I should
 require CARP VIPs (and I suspect that using CARP VIPs is the reason that,
 when the cable modem goes down, I can't get at the pfSense webconfigurator
 until I unplug the WAN cable ... it's OK after I plug it back in, even if
 the cable modem is still down, but it does need to be unplugged???).
 
 My interpretation of the nice chart and notes on
 https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses
 leads me to believe that I can switch the CARP VIPs to be IP Alias VIPs.
 However, when I do that, the 2 servers for the 2 domains tied to the VIPs
 are no longer accessible from the Internet (but IIRC, the mobile VPNs still
 work).
 
 Can anyone suggest what it is that I don't understand (well, limited to
 this behavior, at least)?

Nope, I switched one to be a Proxy ARP VIP ... and it went dead (i.e., site 
becomes inaccessible from Internet), same as when switched to an IP Alias VIP.

Logically, it seems like an alias is what I want since I just want an entry 
point (to the real WAN interface) for the other static IPs, after which 
they're routed/filtered based upon their destination static IP, etc.

The web page reads:

CARP
• Can be used for NAT.
• Can be used by the firewall itself to bind/run services.
• Generates ARP (Layer 2) traffic for the VIP.
...

IP Alias
• Can be used for NAT.
• Can be used by the firewall itself to bind/run services.
• Generates ARP (Layer 2) traffic for the VIP.
...

So, for what I'm doing, an IP Alias VIP seems like it should work where a CARP 
VIP works -- but it doesn't appear that a Proxy ARP VIP should, since I think 
I'm using them by the firewall itself (i.e., port forwarding and NATing) ... 
no -- or does that mean something different?

Proxy ARP
• Can be used for NAT.
• Cannot be used by the firewall itself to bind/run services.
• Generates ARP (Layer 2) traffic for the VIP.
...

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-09, at 2:38 AM, Brian Candler b.cand...@pobox.com wrote:

 On 09/03/2015 09:33, Bryan D. wrote:
 So, for what I'm doing, an IP Alias VIP seems like it should work where a 
 CARP VIP works -- but it doesn't appear that a Proxy ARP VIP should, since I 
 think I'm using them by the firewall itself (i.e., port forwarding and 
 NATing) ... no -- or does that mean something different?
 
 As I understand it, used by the firewall itself means traffic which 
 terminates *on* the firewall: for example, the firewall admin web page, and 
 any services which run on the firewall itself (e.g. DNS cache, packages you 
 have installed)
 
 Traffic which is forwarded *through* the firewall, including NAT, is not 
 addressed to the firewall itself.

So it sounds like the IPsec and OpenVPN traffic would be such traffic?  And it 
also sounds like the regular stuff should work, also.  Is there some 
additional rule that's needed when I switch the VIP to IP Alias from CARP?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-09, at 3:05 AM, Chris L c...@viptalk.net wrote:
 
 On Mar 9, 2015, at 2:56 AM, Brian Candler b.cand...@pobox.com wrote:
 
 On 09/03/2015 09:51, Bryan D. wrote:
 So it sounds like the IPsec and OpenVPN traffic would be such traffic?
 IPSEC traffic is addressed *to* the firewall (at least the IKE stuff on udp 
 500 is, since it is received by strongswan/racoon)
 
 But the firewall already has a public IP address for IPSec.
 
 Are you saying you want different clients' IPSEC tunnels to terminate on 
 different public IP addresses on the firewall WAN side? That I've never 
 tried, and I don't know if it's possible.
 
 It listens (binds) on whatever interface/VIP is specified in the Interface 
 drop-down in the IPSec/OpenVPN config.  If you have a VIP specified, and you 
 change the VIP, you might have to go back and select the new VIP.  Firewall 
 rules other than actual interface addresses are specified by IP address so 
 they should still be good if you change the VIP type.

As I indicated, not changing VIPs, just the VIP type ... change VIP to IP Alias 
type (save, apply, wait a while for change to take effect), dead ... change 
back to CARP type ... works, again. ???

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-09, at 2:56 AM, Brian Candler b.cand...@pobox.com wrote:

 On 09/03/2015 09:51, Bryan D. wrote:
 So it sounds like the IPsec and OpenVPN traffic would be such traffic?
 IPSEC traffic is addressed *to* the firewall (at least the IKE stuff on udp 
 500 is, since it is received by strongswan/racoon)
 
 But the firewall already has a public IP address for IPSec.
 
 Are you saying you want different clients' IPSEC tunnels to terminate on 
 different public IP addresses on the firewall WAN side? That I've never 
 tried, and I don't know if it's possible.

Nope, it's a fully functioning setup (has been, in this form, for a few years) 
... just wanted to switch off CARP VIPs since I'm not using failover.  The only 
question is why won't IP Alias VIPs replace the CARP VIPs?

I can give more detail about things, but the failure mode involves a pretty 
straight-forward setup:

server on LAN -- NAT -- WAN + VIPs -- port-forward -- Internet

VPN on pfSense (IPsec  OpenVPN) -- WAN + 1 VIP -- Internet

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] VIPs : CARP vs IP Alias

[Bryan D.]

On 2015-Mar-09, at 3:11 AM, Chris L c...@viptalk.net wrote:
 
 On Mar 9, 2015, at 3:07 AM, Brian Candler b.cand...@pobox.com wrote:
 
 On 09/03/2015 10:05, Chris L wrote:
 Are you saying you want different clients' IPSEC tunnels to terminate on 
 different public IP addresses on the firewall WAN side? That I've never 
 tried, and I don't know if it's possible.
 It listens (binds) on whatever interface/VIP is specified in the Interface 
 drop-down in the IPSec/OpenVPN config.
 Sure: I was asking if the requirement is to have *multiple* IPSEC VIPs which 
 are processed differently.
 
 If not, then why not just terminate IPSEC on the firewall's primary IP 
 address?
 
 Good question for OP.  As far as I know, racoon and strongswan listen on one 
 binding for all clients. OpenVPN is set per-instance.

We can forget the VPN aspect, here ... what's failing is simple web-site access 
when the VIP type is changed.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] VIPs : CARP vs IP Alias

[Bryan D .]

While we're on the topic, I have a functioning v2.2 setup that uses a /29 set 
of static IPs:
- 1 IP is the gateway address and 5 IPs are usable (quite common, I believe)
- one of the usable IPs is assigned to the WAN interface
- the other 4 usable IPs are assigned to VIPs
- the WAN IP and VIPs have various port-forward and NAT rules associated with 
them
- the WAN IP and 2 of the VIPs serve 3 different domains
  (e.g., web, email, VPN -- servers are behind the firewall on isolated LAN)
- one of the other VIPs is used by mobile VPNs (IPsec and OpenVPN)

All this works nicely ... as long as the VIPs are CARP VIPs.  However, since 
I'm not using any fail-over/redundancy, I don't think I should require CARP 
VIPs (and I suspect that using CARP VIPs is the reason that, when the cable 
modem goes down, I can't get at the pfSense webconfigurator until I unplug the 
WAN cable ... it's OK after I plug it back in, even if the cable modem is still 
down, but it does need to be unplugged???).

My interpretation of the nice chart and notes on
https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses
leads me to believe that I can switch the CARP VIPs to be IP Alias VIPs.  
However, when I do that, the 2 servers for the 2 domains tied to the VIPs are 
no longer accessible from the Internet (but IIRC, the mobile VPNs still work).

Can anyone suggest what it is that I don't understand (well, limited to this 
behavior, at least)?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] NIC Offloading Setting Questions

[Bryan D.]

On 2015-Mar-05, at 11:46 AM, Chris Buechler c...@pfsense.com wrote:

 The description of what's enabled/disabled got confused from Jim's
 earlier post I think. LRO and TSO are both disabled by default,
 hardware checksum offloading is enabled by default.

Just for the record, Jim's message ended with:
---
It’s possible, if everything else is right, then IP checksum offload can 
provide a modest performance improvement, but this is unlikely to be more than 
“noticeable” at the speeds where most individuals run pfSense.   However, at 
10Gbps (or above),
these engines become quite useful.   Support for these is an important 
component of our “3.0” effort.

In case it’s not clear by now, these settings are all *disabled* by default in 
pfSense.
---

It sounds like the all disabled setting would be the safest and, for all 
but the high-volume installs, offer essentially the same performance.  I'll 
update/resend the request to the email address for whomever updates the WiKi.  
Regardless, Jim's explanation helped (some of) us better understand these 
settings.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] NIC Offloading Setting Questions

[Bryan D.]

On 2015-Mar-04, at 6:20 AM, compdoc comp...@hotrodpc.com wrote:

 For me, what happens after enabling or disabling those settings are
 immediately apparent.

I guess my approach w.r.t. a mailing list has always been that I'd like to help 
others avoid spending time learning something I can help with.  As such 
(paraphrasing) try it and you'll see isn't a response I'd give.  Of course, 
in absence of finding the answer in the documentation or via Mr. Google, we can 
always set up a test system and investigate (given the ominous warnings, I 
wouldn't have done so on a production system) ... but then why have the list?


On 2015-Mar-04, at 7:17 AM, Jim Thompson j...@netgate.com wrote:

 Answering any question post-sale is “support”.

Ah, so I should have asked _before_ ordering the NICs?  $;-)


 Does anyone know the answer to my questions about the various offloading 
 settings that should be used with these cards?
 
 LRO works by aggregating [...]
 
 In case it’s not clear by now, these settings are all *disabled* by default 
 in pfSense.

Thank you for an answer that nicely goes above and beyond my expected (we) 
use these settings response.

So your effort can be of maximum benefit, I've submitted a slightly 
edited/formatted version of this to be included in the WiKi's applicable 
pfSense documentation page.


Bryan D.
http://www.derman.com/

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] NIC Offloading Setting Questions

[Bryan D.]

On 2015-Mar-04, at 2:08 PM, Jim Thompson j...@netgate.com wrote:
 
 On Mar 4, 2015, at 2:02 PM, Bryan D. pfse...@derman.com wrote:
 
 On 2015-Mar-04, at 6:20 AM, compdoc comp...@hotrodpc.com wrote:
 
 For me, what happens after enabling or disabling those settings are
 immediately apparent.
 
 I guess my approach w.r.t. a mailing list has always been that I'd like to 
 help others avoid spending time learning something I can help with.  As such 
 (paraphrasing) try it and you'll see isn't a response I'd give.  Of 
 course, in absence of finding the answer in the documentation or via Mr. 
 Google, we can always set up a test system and investigate (given the 
 ominous warnings, I wouldn't have done so on a production system) ... but 
 then why have the list?
 
 You’re aware that I work for Netgate, right?

Well ... yes, but that item was in response to the posting by 
comp...@hotrodpc.com.

More importantly, when I see Jim Thompson I immediately think ah, 
expert-level response follows -- and you always seem to come from the 
understanding that many of us don't breath 'n eat networking.  I sincerely 
appreciate (and learn from) such list/forum/blog/etc. postings.

OTOH, I admit that I've sort o' lumped Netgate with pfSense, assuming little 
separation ... which, I'm guessing is not the right way to think of things.  As 
a low-priority item, it'd be nice to see a statement about this relationship 
(which may already exist, but I was unable to coax it out of Mr. Google -- 
maybe I just don't know the magic phrase).

 
 On 2015-Mar-04, at 7:17 AM, Jim Thompson j...@netgate.com wrote:
 
 So your effort can be of maximum benefit, I've submitted a slightly 
 edited/formatted version of this to be included in the WiKi's applicable 
 pfSense documentation page.
 
 I’m sure the pfSense guys will enjoy that.

... and, hopefully, others.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Suddenly getting pfi_table_update errors [work-around]

[Bryan D .]

I think this issue has been solved:

- issue was errors similar to:
---
[ There were error(s) loading the rules: pfctl: DIOCADDRULE: Invalid argument - 
The line in question reads [0]: ]
---
and/or an error indicating that it can't allocate memory (but there's over 50% 
of the memory reported as being available via the dashboard widget) -- this is 
accompanied by repeating errors like:
---
pfi_table_update cannot set x new addresses into table blah: x
---
and regular I'm completely blocked delays on the web configurator.


- Chris Buechler suggested trying 64-bit, but my machines are not 64-bit capable

- I can't yet test on pfSense 2.2 because it has a broken cas driver (time to 
replace my ol' workhorse Sun 4-port/Gig-e boards)


- when I was writing back to Chris, off-list, I realized that my System - 
Advanced - Firewall/Nat settings for the max firewall tables/entries 
(250/250) were more than I needed so I reduced them to 150/15 (actual 
items about 100/880K):

  + that caused a more complete failure, causing the 2 loading firewall rules 
during the boot-up sequence to show dots but no done and, upon boot-up 
completion, there were errors like:
---
02-17-15 23:51:33   [ There were error(s) loading the rules: 
/tmp/rules.debug:180: cannot define table NotLAN2lans: Cannot allocate memory - 
The line in question reads [180]: table { 172.24.16.0/24 172.24.18.0/24 
172.24.32.0/24 172.24.64.0/29 172.24.48.0/29 172.24.48.32/29 172.24.48.64/29 
172.24.48.96/29 172.24.48.128/29 } ]
---
and none of the tables were created (and I suspect no rules were actually 
loaded, but didn't check).


- given that reducing the max tables/entries values made things worse, it 
seemed obvious that I should try increasing them

... and setting max tables/entries to 300/350 appears to have worked around 
the issue.


My guess is that there's some static memory allocation that's calculated based 
upon the max tables/entries sizes (and other criteria) but that my mix of 
tables, with 10 of them having about 70K entries each, isn't anticipated by 
that memory-allocation calculation.  A static type of allocation wouldn't 
surprise me as I'd assume the rules are very performance-critical.


I've subsequently been able to complete the set of alias/rule changes I was 
making when things broke so, until it fails again, I'll consider this to be an 
OK work-around and hope this write-up will save someone else some 
troubleshooting.

Warning: Thus far, I also have found that:

- one port alias was changed to be a duplicate of the port alias just before it 
in the list and that new name was propagated where it was used within other 
aliases and rules

- one of the URL alias was missing, entirely (and pfSense nicely notified me 
about the affected rules)

... so it should be expected that running out of memory for rules/tables is 
likely to cause some corruption in the configuration if you don't revert to a 
previous config and cause additional memory to be allocated (i.e., don't save 
any config changes after experiencing this kind of memory error).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Suddenly getting pfi_table_update errors

[Bryan D .]

I have a relatively low-traffic pfSense 2.1.5 i386 setup on a system with 1.5 
GB of memory that always shows 50% used.

This setup has normally been reliable but, since upgrading to 2.1.5, today is 
the 4th time I've run into a problem after making changes to some aliases.  For 
some reason that I've been unable to see much pattern to, pfSense will suddenly 
report a rash of errors similar to:
---
[ There were error(s) loading the rules: pfctl: DIOCADDRULE: Invalid argument - 
The line in question reads [0]: ]
---
and/or an error indicating that it can't allocate memory (but there's over 50% 
reported as being available).


When this happens, the following kind of error will occur during the reboot 
while first configuring the firewall ...
---
pfi_table_update cannot set x new addresses into table blah: x
---
where blah varies, even with the same config being rebooted, and seems to 
be either an interface name or self.  The error continues to recur with a 
considerable blocking pause (up to 10's of seconds) each time it (apparently) 
attempts a reload.


I've handled this issue by restoring the most recently saved config.xml (I save 
these _very_ often, now!) and it's been good to go .. after which I can 
remake the changes and all has been good.

However, today that strategy didn't work.  After restoring the previously saved 
config.xml. which had been running without issues for about a day, the 
pfi_table_update problems remained after rebooting.


Thinking it might be a disk-corruption and/or hardware issue, I built another 
system (with similar resources) and tested it.  The same config fails in an 
equivalent way.


QUESTION: Can anyone shed some light on how I might troubleshoot this issue?

QUESTION: Does anyone know what's getting loaded when the message
---
There were error(s) loading the rules: pfctl: DIOCADDRULE: Invalid argument - 
The line in question reads [0]
---
is being issued? ... if I could see the rule that's giving the problem, maybe 
that'd lead somewhere useful.


Other things I've done, without result ...

Of course I asked Mr. Google and searched the pfSense bug tracker for 
pfi_table_update, all without results.

I scanned the disk for an operation called pfi_table_update
(find / -type f -exec fgrep -l pfi_table_update {} \;)
but came up empty-handed so I assume this is not a php/pfSense routine.

My first thought when it occurred was that the config.xml file had become 
corrupted, but I've never found any evidence of that.  I've always compared the 
failed config to the successfully reverted config and found no clues (lately, 
since I save configs so often, there's only been 2 or 3 changes).  The only 
thing that's been consistent is that the problem always pops up (literally!) 
after editing aliases and the rules are being reloaded.

I'm always careful to change aliases in a way that works from the bottom of the 
dependencies up (when applicable) and, though I do have aliases that include 
other aliases, I doubt there's anything unusual in either structure or number 
of aliases I have configured (84 host/network aliases, 67 port aliases and 63 
URL aliases).

The only thing (related to the aliases) that may be unusual is that I have 
about 10 large URL tables (70K entries, each) and have things configured for 
250 tables (currently 100) and 2,500,000 table entries (currently about 680K 
entries).  It's the tables that consume memory, not states, in our case.

Any ideas?  grovel, grovel  #;-)

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Multiple Roadwarrior OpenVPN on my PFSense server

[Bryan D.]

On 2015-Jan-19, at 8:28 PM, Mark Wass m...@market-analyst.com wrote:

 snip'd
 
 I've checked my WAN firewall rules and can see that the Wizard has added an 
 open port to 1196 in the rules.
 
 Is there some sort of rule that does not allow me to have multiple OpenVPN 
 servers running? I have 3 other PFSense site-to-site OpenVPN's working okay, 
 I cant see why this one would be causing me so much trouble.
 
 Thanks.
 
 Mark

You might find some of the following stuff to be helpful:

http://www.derman.com/blogs/Setting-Up-iOS-OnDemand-VPN

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] viscosity, openvpn, and pfsense

[Bryan D.]

On 2015-Jan-19, at 1:48 PM, Jeremy Porter jpor...@electricsheepfencing.com 
wrote:

 The configuration your trying to use in pfsense is TLS Authentication,
 which is a static (shared) TLS key.
 
 In the Server Mode box, you need to select SSL/TLS or SSL/TLS User
 authentication.
 You will need to configure your CA and Openvpn server keys under the
 System-Cert Manager settings.

We're using SSL/TLS User authentication with pfSense-generated CA  certs 
and, beginning with 2.1.5, have the same thing happening.  Note that, despite 
the (seemingly erroneous) error message, OpenVPN continues to work (i.e., 
existing and new [mobile, in our case] connections work as always).  In our 
case, this started occurring immediately after we updated to 2.1.5 (no changes 
to OpenVPN or the mobile clients).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Route OpenVPN traffic to the available IPSec tunnels

[Bryan D.]

On Wed, Dec 24, 2014 at 5:15 AM, Lorenzo Milesi max...@ufficyo.com wrote:
 Hi. Is it possible to route OpenVPN clients to the available IPSec routes?
 
 I currently have 3 IPSec tunnels on my pfSense, and seldomly I need to access 
 those routes outiside my office. Is it possible to do so?
 In my firewall rules I have no restrictions, all traffic is allowed. I tried 
 adding the route manually but apparently this is not enough because pfSense 
 won't route my packets to the tunnel. Has this something to do with IPSec's 
 phase2 entry?

See 5. Routing OpenVPN through IPSec VPN on pfSense at
http://www.derman.com/blogs/IPSec-VPN-Firewall-Setup#RouteOpenVPNthruIPsec

(same approach required if multiple LANs are involved and one or more 
systems/subnets require access to multiple remotely located LANs)

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Network Topology - Home Lab

[Bryan D.]

On 2014-Jun-29, at 8:00 AM, Jonatas Baldin jonatas.bal...@gmail.com wrote:

 If I make a mobile IPsec VPN in the pfSense box, will I get access
 normally to the LANs?
 
 You will need to tell IPsec to tell its clients that they can reach all
 the networks over the VPN connection (The clients need to know to route all
 traffic for 10.0.0.1/24, 192.168.10.0/24, 192.168.20.0/24, and possibly
 172.16.0.0/24 over the VPN connection).


I've put up a bunch of stuff on iOS VPN with pfSense that could be of some help 
in this:
http://www.derman.com/blogs/Setting-Up-iOS-OnDemand-VPN

Bryan D.
http://www.derman.com/
 

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Interface yoyo

[Bryan D.]

On 2014-Apr-21, at 6:28 AM, Jim Pingle li...@pingle.org wrote:

 snip'd
 
 The Spoofed MAC address issue was a problem in the past with certain
 drivers that sounds very similar because it got into a chicken-and-egg
 scenario that went a little something like this:
 
 * pfSense sets the MAC address
 * The NIC driver resets its own link on the MAC change
 * The link down/up triggered pfSense to reconfigure the NIC
 * pfSense sets the MAC address again while reconfiguring the NIC
 * The NIC driver resets its own link on the MAC change
 * The link down/up triggered pfSense to reconfigure the NIC
 * [lather, rinse, repeat]
 
 We added some extra checks before resetting the MAC to prevent that sort
 of thing from being a problem though, but it's possible that the HME NIC
 is resetting its link when some _other_ setting is being applied. If you
 have any special configuration on the NIC (spoofed MAC, custom MTU,
 specific link speed, etc) it would help to know.
 
 Jim

FYI, in my case there was no MAC spoofing and the issue occurred when an hme 
port was used for a LAN and/or WAN interface.  I don't have the resources, 
right now, but it'd be good if someone could try a raw OS-only install and 
see whether the issue exists there.  Presumably that would eliminate pfSense's 
code or make it the more likely source.

Again, in my case, it was only necessary to have the link go down once (e.g., 
unplug/re-plug the cable) and the runaway cycle was started ... so a native 
OS-only test should be easy.  Given that the hme's are inexpensive, still 
readily available, seem to last forever and are very reliable, it's kind of a 
shame not to be able to use them any more (yes, I dp have some Scottish 
heritage).

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Interface yoyo

[Bryan D.]

On 2014-Apr-20, at 12:33 AM, Volker Kuhlmann list0...@paradise.net.nz wrote:

 Ever since upgrading to pfsense 2.1 I have been let down by it. It looks
 like there are multiple issues and I am trying to separate them. One is
 system suicide by memory gobbling - but it's been a little tricky to
 find out why exactly.
 
 snip'd
 
 Sun 4-port Ethernet NIC
 hme0: Sun HME 10/100 Ethernet mem 0x4600-0x46007fff irq 21 at device 
 0.1 on pci3
 miibus2: MII bus on hme0
 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus2
 ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 hme0: [ITHREAD]
 [and 3 more of these]
 
 snip'd
 
 How can I get this pfsense box back into the same reliable and
 dependable system it used to be before 2.1?
 
 Any suggestions appreciated. Happy to provide more info too - but where
 do I start looking?
 
 Thanks muchly,
 
 Volker
 
 -- 
 Volker Kuhlmann
 http://volker.top.geek.nz/Please do not CC list postings to me.
 ___

I reported this issue with the HME's a while ago (it's nasty!):
bug #3481 -- https://redmine.pfsense.org/issues/3481

Executive summary: replace the NIC with a different model.  Too bad, they used 
to work very well and virtually never die.

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

[pfSense] Unable to access via static route

[Bryan D .]

I have an issue that I've been unable to solve and could use some suggestions 
(or confirmation that it can't be done).

Background
--
The problem is that I can only access IPs on the other side of a VPN connection 
via a static route when on one of our LANs.  Here's an overview of the setup 
that I think is pertinent:

- pfSense 2.1 release (at both sites)

- LAN1 : 172.24.24.0/24 - pfSense: 172.24.24.1
- LAN2 : 172.24.25.0/24 - pfSense: 172.24.25.1
- other-site LAN: 172.24.32.0/24 - pfSense 172.24.32.1

- Routing:
  WAN_Gateway/default ...
  LAN_Gateway  LAN1  172.24.24.1  172.24.32.1
  static route:
172.24.32.0/24  LAN_Gateway/172.24.24.1  LAN1

- VPNs:
  always-on IPSec LAN1 (172.24.24.0/24) -- other-site LAN (172.24.32.0/24)
  mobile: IPSec 172.24.64.0/24 with 172.24.64.1 gateway
  (P2:Local Network is 0.0.0.0/0 to run all mobile's traffic through our net)
  mobile: OpenVPN 172.24.48.0/24 with 172.24.48.1 gateway
  (OpenVPN:Force all client generated traffic through the tunnel. is ON)

- pfSense lists built-in routes for:
  172.24.24.0/24
  172.24.25.0/24
  172.24.32.0/24
  172.24.48.0/24
  172.24.64.0/24

- NATs:
  all except other-site LAN subnets are NAT'd to WAN
  LAN1 is NAT'd to LAN2
  LAN2 is NAT'd to LAN1
(I actually don't remember what didn't work without those LAN-toLAN NATs and 
don't understand why the default routing shouldn't make them unnecessary -- 
comments would also be welcome on this one)


What Works
--
Systems on LAN1 (172.24.24.0/24) CAN access IPs on other-site LAN 
(172.24.32.0/24), presumably via static route (and vice versa, inverse static 
route also defined at other-site end).

Systems connected via mobile IPSec VPN (172.24.64.0/24) and OpenVPN 
(172.24.48.0/24) CAN access IPs on LAN1 (172.24.24.0/24) and LAN2 
(172.24.25.0/24).


Problems

Systems on LAN2 (172.24.25.0/24) CANNOT access IPs on other-site LAN 
(172.24.32.0/24)
- LAN2 rule pass all for source LAN2 (172.24.25.0/24) exists

Systems connected via mobile IPSec VPN (172.24.64.0/24) CANNOT access IPs on 
other-site LAN (172.24.32.0/24)
- IPSec rule pass all for source 172.24.64.0/24 exists

Systems connected via OpenVPN (172.24.48.0/24) CANNOT access IPs on other-site 
LAN (172.24.32.0/24)
- OpenVPN rule pass all for source (172.24.48.0/24) exists


QUESTION

Is there a way to get pfSense to route LAN2 (172.24.25.0/24), mobile IPSec 
(172.24.64.0/24) clients and OpenVPN (172.24.48.0/24) clients to the other-site 
LAN (172.24.32.0/24) that's connected via IPSec VPN and, if so, how?

FYI, I tried but couldn't figure out how to set up another static route between 
those other subnets and the other-site LAN -- pfSense had a problem with 
anything I attempted ... so, if that's the answer, please be specific about how 
to do it.

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] pfsense openvpn Road Warrior

[Bryan D.]

On 2014-Mar-19, at 2:24 AM, A Mohan Rao mohanra...@gmail.com wrote:

 Hello Team,
 
 Hello,
 i have configured openvpn road warrior also client is properly connected
 from outside internet network.
 but not able to access server end network and servers's.
 can anybody give any help where is do any wrong steps.
 
 Thanks
 
 Mohan

I've been working on trying to document a fairly complete pfSense/iOS 
IPSec/OpenVPN with iOS 7 VPN on-demand.  Though I still have the on-demand 
stuff to write up, the rest of it's there so some of it may be of use:

http://www.derman.com/blogs/Setting-Up-iOS-OnDemand-VPN

It's quite new, so feel free to let me know of any issues, suggestions, etc.


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Multiple static IPs from one ISP - Virtual IPs? - Trying this again

[Bryan D.]

On 2014-Mar-02, at 11:52 PM, Ryan Coleman ryanjc...@me.com wrote:

 How do I set up multiple static addresses? I used Virtual IP to create x.2 
 and I can ping it internally but not externally.
 
 I’ve tried using guides I’ve found online but I cannot seem to get them to 
 work.
 
 What I want to do is have (for the time being) x.2 to assign out port forward 
 assignments (FTP, SMTP, IMAP, WWW, etc.). Everything points to using Virtual 
 IPs but I cannot seem to gather how they’re supposed to route data out.
 
 What am I missing?

If I understand your requirements, to go out a VIP, you need to create a NAT 
rule where the NAT Address is the VIP's IP.  There are some limitations with 
VIPs but they can all be NAT'd:
https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses?

I've pretty much always used Manual Outbound NAT, so I no longer remember 
what's created automatically, etc.

E.G., when I want to send my desktop's traffic out via one of our static IP 
VIPs (tied to the WAN interface) instead of using the normal WAN interface's 
static IP, the following Outbound NAT rule takes care of it:
WAN  desktop's IP  *  *  *  IP of VIP  *  NO  description

That plus an applicable LAN rule goes a long way.

Hope that helps a little.

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Multiple static IPs from one ISP - Virtual IPs? - Trying this again

[Bryan D.]

PiBA was correct: only the WAN rule is required for pings (learn something new 
every day!).  My testing was via an outside network as pings always work 
internally, with our setup.

Previously you wrote:
I’ve done this, but I won't route traffic out (NAT) until I have verifiable 
traffic coming in.

Not sure when it comes to ping response whether that's required, or not (I'm 
guessing not ... PiBa: do you know for sure?).


On 2014-Mar-03, at 1:45 PM, Ryan Coleman ryanjc...@me.com wrote:

 Everything pings inside… but nothing pings from outside.
 
 If I get out of the confines of my subnet I cannot get a response. If I ping 
 from another public server in my subnet it pings on WAN, if I do it from 
 behind the firewall it does it on LAN. But from another server outside: 
 nothing. X.1 pings without an issue on the WAN port.

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] multiple openvpn instance routing issue.

[Bryan D.]

FWIW, I was having similar problems crossing LANs on a 2-LAN/5-WAN (1 real/4 
VIPs) setup and ended up solving it using NAT (pfSense v2.1 release).

The setup is using Pure NAT (in System - Advanced - Firewall/NAT) along 
with Manual Outbound NAT rules and what I had to do was NAT from LAN to LAN -- 
specifically, in Outbound NAT:
LAN1   LAN2   *   *   *   LAN1 address   *   NO   NAT LAN2 to LAN1
LAN2   LAN1   *   *   *   LAN2 address   *   NO   NAT LAN1 to LAN2
(aliases are defined to abstract both LAN1 and LAN2 and the LANx address is 
the usual Interface Address setting)

I still don't understand why routing doesn't take care of it and why NAT is 
required for certain things to work, but this was the only way I could get it 
to work in my setup.  Of course, I'd like to be educated if someone has an 
answer.

Bryan D.
http://www.derman.com/
 

On 2014-Feb-26, at 11:41 AM, Muhammad Yousuf Khan sir...@gmail.com wrote:

 i am using two instance one on port 1194 and one on 1196
 1194 is preshared for dd-wrt working fine.tunnel subnet is 10.3.3.0/24.
 
 1196 is remote acess for road warriers.tunnel subnet is 10.4.4.0/24
 
 i want both my VPN segments to use my headoffice LAN and can also connect
 to each other as hub and spoke.
 
 
 both VPN properly setup and working fine. i can acess pfsense LAN segment
 from remote site and from road worrier both. however when i try to access
 10.3.3.0/24 from 10.4.4.0/24 clients it does not reach
 
 i know you might be saying it is a routing issue. however further analysis
 says something else.
 
 my dd-wrt can reach 10.4.4.1 (pfsence interface) after i define the static
 route in dd-wrt router.
 but my dd-wrt router can not reach 10.4.4.10( which is an ip of my road
 warrier windows laptop)  and at the same time my lapton can reach 10.4.4.1
 and LAN segment also. but can not reach 10.3.3.1(which is pfsence
 interface).
 
 
 i set a route for 10.3.3.0/24 with gateway of 10.4.4.1 in windows laptop
 but still i can not reach the 10.3.3.1
 
 ...

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Run-Away Processing Issue

[Bryan D.]

On 2014-Feb-19, at 6:17 AM, Jim Pingle li...@pingle.org wrote:

 Try pfSense 2.1.1. There were some issues with link cycling in certain cases 
 that you might be hitting which were fixed on 2.1.1.
 
 https://forum.pfsense.org/index.php/topic,71546.0.html
 
 Jim
 
  On 2/19/2014 2:07 AM, Bryan D. wrote:
 ...
 The problem is that whenever the WAN interface link on the pfSense box goes 
 down, pfSense goes into some sort of loop/run-away condition and requires a 
 reboot...
 
 The issue is detailed at:
 http://www.derman.com/pfSense-Run-Away-Issue
 ...

Thanks, Jim.  It looks like this is an still-present issue with hme NICs that 
are used for a monitored interface.  I've updated the above web page with what 
I think I learned and filed a bug report:
https://redmine.pfsense.org/issues/3481

If anyone else is still using an ol' tank 4-port hme cards (1990's Sun 
Microsystems 100 Mbit NIC) and has any of their ports assigned to a monitored 
interface, it'd be interesting to hear whether they are experiencing the same 
issue (v2.1-Release or newer).

To test, simply unplug the hme interface's ethernet cable, wait 10 seconds, 
then plug it back in and monitor pfSense's processor activity.  For my tested 
configs, if it's not settled down to something less than 100% CPU activity 
within about a minute, it's in run-away -- but be forewarned, if it goes into 
run-away, AFAIK you'll need to reboot.

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] Run-Away Processing Issue

[Bryan D.]

I have a problem that I've been unable to make much progress with and could use 
some suggestions on how to proceed.

The problem is that whenever the WAN interface link on the pfSense box goes 
down, pfSense goes into some sort of loop/run-away condition and requires a 
reboot.  This problem is 100% reproducible (and turns a short loss of service 
into an on-going failure).

The issue is detailed at:
http://www.derman.com/pfSense-Run-Away-Issue

Any help would be appreciated.  I've setup a duplicate test system setup so I 
can examine any ideas and troubleshoot without bringing down our network.

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] OpenVPN Keep-Alive Setting

[Bryan D .]

I hope I'm not just having a senior's moment, but I can't find any place on 
the GUI where the OpenVPN server's keepalive option is set but one is being 
generated in the server config file.

I'm running pfSense 2.1 release.  Couldn't find an answer via the pfSense 
forums or via Mr. Google nor could I see anything in pfSense's config/xml file.

Can someone point me to the pfSense settings page where it's set (assuming 
there is one)?

If it's hard-coded into the unit that generates the server config, which unit 
is that and is there a preferred way to override it (maybe something that can 
be manually inserted into the config/xml file so it survives reboots)?

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Is there a would it pass/what-if capability?

[Bryan D.]

Does pfSense have a crowd funding page for projects (I've never seen one)?  
At the risk of creating more work for someone, having a page that lists 
something such as project name and description, funding requirement, estimated 
delivery method and timing once funded along with some buttons to allow 
contributions via credit card and PayPal funds could go a long way to getting 
things like this rolling.

If it was me, I'd have the start of each potential crowd funded project be a 
forum and list announcement of a set-time interest survey (say 1 week) that 
would allow people to express how much money they'd be willing to donate and 
that would give an idea of the viability of the request as a crowd-funded 
effort.  I wouldn't be surprised if some such open-source web software already 
exists.

I'd definitely be willing to contribute a small amount to such a would it 
pass/what-if capability to be added to pfSense.  While I'm a little surprised 
that something like this doesn't already exist, given its obvious value, I'd 
also guess that it'd be a rather involved task.


On 2013-Mar-20, at 11:16 AM, Jim Pingle li...@pingle.org wrote:

 On 3/20/2013 1:58 PM, Bryan D. wrote:
 Thanks.  I was hoping someone, likely the pfSense guys if it didn't already 
 exist, had developed a command/tool that would allow one to ask pf's 
 filtering mechanisms whether this could talk to that via the current 
 config/rules.  It seems that this would be not only invaluable for (at least 
 preliminary) testing, but would also be good for admins to check whether 
 they seem to have gotten things configured correctly.
 
 Doesn't exist yet, but it's something we've thought about.
 
 http://redmine.pfsense.org/issues/2771
 
 If someone wants to code it or fund it, it might show up in a release
 sooner rather than later...
 
 Jim

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Is there a would it pass/what-if capability?

[Bryan D.]

Thanks.  I was hoping someone, likely the pfSense guys if it didn't already 
exist, had developed a command/tool that would allow one to ask pf's filtering 
mechanisms whether this could talk to that via the current config/rules.  It 
seems that this would be not only invaluable for (at least preliminary) 
testing, but would also be good for admins to check whether they seem to have 
gotten things configured correctly.

Bryan D.
http://www.derman.com/
 

On 2013-Mar-20, at 2:51 AM, mayak-cq ma...@australsat.com wrote:

 On Tue, 2013-03-19 at 23:19 -0700, Bryan D. wrote:
 
 I've searched both the list archives and forums, though I wasn't sure what 
 phrase would yield results, and have not found an answer to the question:
 ---
 Is there a way to ask pfSense something like would a UDP|TCP packet 
 arriving on interface port from IP address be passed to IP address 
 on interface port?
 
 In short, is there a way to quickly test the rule/NAT behavior (i.e., 
 without actually having created the subject WAN setup)?
 
 hi bryan,
 
 i use nmap setting source and destination ports -- i run nmap on boxes
 infront of and behind pfsense.
 
 i am not aware a `tool` that does this.
 
 cheers
 
 m
 ___
 List mailing list
 List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list