Re: [pfSense] newbie question
Pol Hallen wrote on Mon, Mar 23 2015 at 5:09 am: adsl -- server1 -- WAN pfsense (2 NICs) LAN -- internal lan (I known that pfsense should be after adsl modem) does ipsense runs correctly with this configuration? WAN to server1 LAN1 to internal lan or I must add a third NIC and connect LAN1 to server1 and LAN2 to internal lan? Is pfSense running on server1? Or is server1 supposed to be in a DMZ? If pfSense is separate from server1, then yes you will need another NIC. Otherwise all Internet traffic will go to server1 and not get to pfSense. Or, if server1 connects to the Internet directly, and pfSense connects to the Internet separately (so they are in parallel), and you have two WAN IP addresses, that will work. -- Steve Yates ITS, Inc. ___ 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
On 03/22/2015 12:38 AM, Bryan D. wrote: 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). snip i have to say that i am also experiencing this. i'm in the process of installing smokeping to prove connectivity is good between the public ip endpoints between various vpns. will report back with those results. thanks m ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] newbie question
Hi all :-) my lan (for purpose testing): adsl -- server1 -- WAN pfsense (2 NICs) LAN -- internal lan (I known that pfsense should be after adsl modem) does ipsense runs correctly with this configuration? WAN to server1 LAN1 to internal lan or I must add a third NIC and connect LAN1 to server1 and LAN2 to internal lan? thanks for help! Pol ___ 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
I am having issues as well. 2.0.0 -- 2.0.3 works fine. Upgraded to 2.2.1 and the connection always fails within 24 hours. Please let me know how the 2.2.1 x 5 setup works. On Mon, Mar 23, 2015 at 1:40 PM, Jeremy Bennett jbenn...@hikitechnology.com wrote: Yes. I have 5 sites (of various 2.0+ pfsense) connected via IPSec. Historically, this setup was the definition of stable. Since adding a 2.2 box it has been flaky as all get out. I'm in the process of upgrading each location to 2.2.1. Hoping that will be the easy fix, if not, will have to start chasing it. On Monday, March 23, 2015, mayak ma...@australsat.com wrote: On 03/23/2015 03:03 PM, mayak wrote: On 03/22/2015 12:38 AM, Bryan D. wrote: 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). snip i have to say that i am also experiencing this. i'm in the process of installing smokeping to prove connectivity is good between the public ip endpoints between various vpns. will report back with those results. thanks m __ it is happening -- three times since last post ... anyone else noticing vpn outages? thanks m ___ 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 ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] ipsec and multi-wan
On Thu, Mar 19, 2015 at 12:48 PM, Gregory K Shenaut gkshen...@ucdavis.edu wrote: Hi, I have a system with two sites. One of the sites has two WAN connections, the other one. I have an IPSEC tunnel passing all traffic between the two sites. I'm having some difficulty with site-to-site access. I can ping anything in either site from either site, but can't do much of anything else. For example, I can't open web pages across the tunnel: sometime I get nothing, sometimes a hundred or so characters then nothing else. When I try to transfer lots of data across the tunnel, typically I get some initial data, again a hundred or so characters, then it hangs, and, frequently, the tunnel itself goes down and I have to wait for it to re-establish itself. Almost certainly needing MSS clamping. Advanced settings tab, check that box there. Then start new connections (may want to kill states just to make really sure), and things will probably work. I've tried all sorts of things, and I believe that there may be a problem in routing due to the dual-WAN setup on one of the sites. I'm not entirely certain, but it's possible the problem began when I set up dual-WAN. I'm on pfsense 2.2.1. There is a sentence in the documentation at https://doc.pfsense.org/index.php/VPN_Capability_IPsec under Prerequisites: If pfSense is not the default gateway on the LAN where it is installed, static routes must be added to the default gateway, pointing the remote VPN subnet to the IP address on pfSense in the LAN subnet. Is that actually the case? VPN is on a separate box from the default gateway on the LAN? I've tried adding various static routes based on my understanding of that sentence, but they haven't helped, which is why I'm asking this question. First, preliminary question: when you make a change to the System Static Routes web page and apply it, it seems like sometimes older routes aren't deleted. Is it necessary to reboot every time you change the static routes to make sure that you get rid of ones you deleted or deactivated? Never necessary to reboot. Where are you seeing they're still there? Routes being there after you deleted the static route is generally indicative of something else adding them back, like a dynamic routing protocol, or them being in an OpenVPN client or server, or similar. ___ 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
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
There's nothing to go on to offer any worthwhile suggestions. IPsec logs best place to start. On Mon, Mar 23, 2015 at 6:02 PM, Bryan D. pfse...@derman.com wrote: 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 ___ 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
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
Re: [pfSense] CARP failover works but it only fails back the LAN
I am not sure this is related but it is weird/bad...I got around to setting the skew back to 0 for all CARP IPs on router1. pfSense (2.2.1) syncs the change to router2 so those skews change from 101 to 100. However afterwards router1 shows all five as Status of Master, and router2 shows all five with a blank Status. I must edit each of the five, save (without making changes) and only once changes are Applied the Status shows as Backup. That sounds like a configuration sync bug? I did see this when setting the skew from 0 to 1 earlier today and passed it off as I was clicking around a lot, but it seems to be repeatable. -- Steve Steve Yates wrote on Mon, Mar 23 2015 at 2:50 pm: Just ran into an odd scenario in my testbed...if pfSense (router1) is in a VM (Parallels Cloud/Virtuozzo), and I run service network restart on the host for that VM, pfSense fails over the WAN interface but does not fail over the LAN interface. At that point external communication is lost because one router is handling LAN and one WAN. It does not seem to recover afterwards until the host is restarted (we're also using VLANs on the host level for the pfSense VM to use for its interfaces, so that may be a factor in having the host restart). Per http://www.freebsd.org/cgi/man.cgi?query=carpsektion=4, if net.inet.carp.preempt=1 then the CARP interfaces should fail over together. Running sysctl net.inet.carp on pfSense shows net.inet.carp.preempt=1. If I reload the CARP status page on router2 quickly, I can see that the WAN and LAN interfaces correctly fail over so router2 is Master, however it almost immediately reverts so router2 is Master for WAN but router2 is Backup for LAN, and router1 is Master for LAN. How can I ensure they fail back together? Note that when I simply boot the host for router1, pfSense does fail over and back correctly! So something is making it not fail back on the network restart? For what it's worth we have a IPv4 and IPv6 CARP IPs for WAN, and an IPv4, an IPv4 alias, and IPv6 CARP IP for LAN. I found an OpenBSD (which I know is different OS, but...) FAQ page on CARP that says By default all carp(4) interfaces are added to the carp group. However if I run ifconfig -v on pfSense no groups are listed for em0 and em1, only lo0, enc0, and ovpns1. I created a pfSense interface group carpgroup for LAN and WAN, but had the same symptoms. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] ipsec and multi-wan
On Mar 23, 2015, at 17:31 , Chris Buechler c...@pfsense.org wrote: On Thu, Mar 19, 2015 at 12:48 PM, Gregory K Shenaut gkshen...@ucdavis.edu wrote: Hi, I have a system with two sites. One of the sites has two WAN connections, the other one. I have an IPSEC tunnel passing all traffic between the two sites. I'm having some difficulty with site-to-site access. I can ping anything in either site from either site, but can't do much of anything else. For example, I can't open web pages across the tunnel: sometime I get nothing, sometimes a hundred or so characters then nothing else. When I try to transfer lots of data across the tunnel, typically I get some initial data, again a hundred or so characters, then it hangs, and, frequently, the tunnel itself goes down and I have to wait for it to re-establish itself. Almost certainly needing MSS clamping. Advanced settings tab, check that box there. Then start new connections (may want to kill states just to make really sure), and things will probably work. This worked like a champ! I didn't know that option existed. Thank you. Greg 've tried all sorts of things, and I believe that there may be a problem in routing due to the dual-WAN setup on one of the sites. I'm not entirely certain, but it's possible the problem began when I set up dual-WAN. I'm on pfsense 2.2.1. There is a sentence in the documentation at https://doc.pfsense.org/index.php/VPN_Capability_IPsec under Prerequisites: If pfSense is not the default gateway on the LAN where it is installed, static routes must be added to the default gateway, pointing the remote VPN subnet to the IP address on pfSense in the LAN subnet. Is that actually the case? VPN is on a separate box from the default gateway on the LAN? I've tried adding various static routes based on my understanding of that sentence, but they haven't helped, which is why I'm asking this question. First, preliminary question: when you make a change to the System Static Routes web page and apply it, it seems like sometimes older routes aren't deleted. Is it necessary to reboot every time you change the static routes to make sure that you get rid of ones you deleted or deactivated? Never necessary to reboot. Where are you seeing they're still there? Routes being there after you deleted the static route is generally indicative of something else adding them back, like a dynamic routing protocol, or them being in an OpenVPN client or server, or similar. ___ 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
Re: [pfSense] Locked myself out by disabling LAN
On Mon, Mar 23, 2015 at 9:05 PM, Jean-Stéfane Bergeron j...@jsbergeron.ca wrote: I'm on the road for another two weeks - is there anyway I can re-enable my lan or connect to my router remotely to restore access? Or am I pooched until I can get back to my router physically? Without one of shell (console, ssh) or web access, you're pretty stuck. Since you applied the change, a reboot won't help. Usually when I'm on the road I have a red light switch tied to critical equipment that friends/family/petsitters can manage without too much drama. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Locked myself out by disabling LAN
Good evening everyone, I ran into a problem with my pfsense install today. I'm connecting remotely over a VPN connection to my network. For some reason, all my local devices became inaccessible today. My VPN connection still can connect to my network. When I logged into my router, I noticed that the lan connection was down. In an attempt to restart the lan connection I disabled it ... I thought I'd be able to restart it - that was Dumb! You probably know that I am now unable to connect to my router's web interface. I can still connect to the VPN interface and get an IP address from the VPN subnet, but nothing to fix my stupidity. I'm on the road for another two weeks - is there anyway I can re-enable my lan or connect to my router remotely to restore access? Or am I pooched until I can get back to my router physically? Thanks for your help! I'm so disappointed in my own stupidity! __ Sent from my iPhone ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
