Re: [pfSense] Moving traffic between LAN & OPT1
> On Dec 24, 2017, at 9:45 AM, Chris L wrote: > > Not a bug. That is by design. Create the rules to pass the traffic you need > to pass on OPTX interfaces after you create them. That's inconsistent with the LAN interface which has secret undocumented default rules that allow self traffic to the firewall from the interface network segment by default. To me this inconsistency does feel like a bug. >> Again, not a bug. There's a long open bug for it actually: https://redmine.pfsense.org/issues/5826 It will break your configuration whenever you configure IPSec between an OPT* and a remote destination whose CIDR block happens to be a superset of your interface CIDR block and you have been using any local service like DNS, HTTPS, SSH, etc. on the firewall. The traffic will be misrouted through the tunnel due to missing logic for bypassing the firewall self traffic from the tunnel. Matthew. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Moving traffic between LAN & OPT1
I did run into various bugs involving interfaces != LAN. One common one is that the other interfaces are missing a default allow rule for reaching pfSense on 53/udp. This makes all your DNS requests fail and then it can seem like none of your stuff is working. Another problem you can find is, if you use IPsec or another site to site VPN, these other interfaces don't have a bypass rule preventing self-traffic to the firewall from being forced through the VPN tunnel. So I'm not sure what configuration you've got but there are some funny things you can see. I will say that once I worked around these items I was easily able to move or block traffic between LAN and the other interfaces with no issues. One trick that can help with the debugging is to replace the implicit default block rule with a default reject rule so you can easily see what's misconfigured on the end nodes and watch the firewall for log messages on your rules with logs enabled to see why your traffic refuses to flow. Matthew Hall > On Dec 23, 2017, at 6:53 PM, Walter Parker wrote: > >> On Fri, Dec 22, 2017 at 8:25 PM, Antonio wrote: >> >> Hi, >> >> I'm not sure how you move traffic between the above interfaces. I was >> under the impression that all you needed was a "Default allow LAN to any >> rule" and job done. Yet i'm struggling to get devices of different >> interfaces to communicate. What am I missing? >> >> That rule allows the LAN to move traffic. Traffic on OPT1 is a different > network. You will have addition rules to allow it talk to LAN. You will > need to add two sets of rules (or floating rules) depending on how you wish > to design your network. > > > Walter > > > >> >> Thanks >> >> >> >> -- >> >> >> Respect your privacy and that of others, don't give your data to big >> corporations. >> Use alternatives like Signal (https://whispersystems.org/) for your >> messaging or >> Diaspora* (https://joindiaspora.com/) for your social networking. >> >> ___ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold >> > > > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis > ___ > 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] IPv6 1:1 NAT problems
This bug report is absolutely insane. It required more hours for people to compose these replies than it would to compose the patch for the actual bug. I couldn't even read it all because it was so violently toxic. Matthew Hall > On Aug 2, 2017, at 9:36 PM, Morgan Reed wrote: > > It's not "google" refusing to support it... It's one Lorenzo Colitti who is > the roadblock... > https://issuetracker.google.com/issues/36949085 > But yes, it's asinine. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPv6 1:1 NAT problems
If you put your network segment into Assisted Mode the clients will try SLAAC followed by DHCPv6 so that things can cooperate between both approaches. Matthew Hall > On Aug 2, 2017, at 8:00 PM, Adam Thompson wrote: > > You could be right, I was writing from memory and ... tbh, I don't care > enough to go look it up again :). They shut down, that's a pain in the butt, > I was already on HE anyway, end of story for me. > I would do the same here, except that (IMHO) Google's refusal to support > DHCPv6 on Android is completely asinine. So my phone still doesn't get an > IPv6 address here at home :-(. > (Note: Apple products work perfectly.) > > It's interesting to speculate about what will happen at some future date when > HE turns off (or starts charging for) their tunnel service... I haven't > heard anything credible yet, but I assume it'll happen someday. > > -Adam ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPv6 1:1 NAT problems
https://tools.ietf.org/html/rfc6296 Matthew Hall > On Aug 2, 2017, at 7:19 PM, Vick Khera wrote: > > Is NAT even a thing with IPv6? > ___ > 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] IPv6 problem at OVH
On Tue, Aug 01, 2017 at 11:27:50PM +0200, Olivier Mascia wrote: > The real issue is that HA setup of a couple of pfSense is impossible with > such an awkward IPv6 setup as OVH imposes to us. Just curious: how does it break CARP + pfSync? ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPv6 problem at OVH
On Tue, Aug 01, 2017 at 01:57:01PM -0500, Adam Thompson wrote: > *** As a consequence, all IPv4 addresses must respond to ARP, and all IPv6 > addresses must respond to NDP, in order to be successfully publicly routed. The last time I had this issue, I had a Fortinet installed, and I used this featureset: I don't think the PFSense currently exposes the NAT66 for configuration. When you use it, you can use an internal ULA subnet from a ULA generator, and use NAT66 to get the right exterior origin. http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-IPv6-54/IPv6%20Features/IPv6_NAT.htm It would be best solved using IPv6 VIPs for the inbound NAT. I have tested that and had it working on Linux and PFSense myself. The other thing you can perhaps do, since they sent you a whole /56, is hand out /64s inside the PFSense that are chopped out of the /56 given to you. I've done that in my house using DHCPv6-PD from Comcast. But it should be possible with classic DHCPv6 and some static routes and/or a routing protocol inside your setup. It depends just how their layer 2 restrictions work. In my colo company it was fine because I didn't have to directly do ARP / NDP as long as I could route properly both ways. > (NDP for an entire /56? Fee fi fo fum, I smell a DoS attack...) Yes.. this problem was called out during the lead-up to World IPv6 Day and World IPv6 Launch in 2011 and 2012. https://en.wikipedia.org/wiki/World_IPv6_Day_and_World_IPv6_Launch_Day Some patches to rate-limit the priority and request rate of new NDP neighbor adjacency discovery were added to the vast majority of major Cisco, Juniper, ... etc. router firmwares. Matthew. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPSec tunnels on AT&T U-Verse
Try enabling and reading the debug logs first to scavenge some output from both tunnel ends. I found a lot of my brokenness enabling and reading the docs listed in PFSense's debug log listing wikipage for IPSec linked in my previous mails. It saves a lot of time over going in blind if you can catch some more specific issues from those logs. Matthew Hall > On May 15, 2017, at 8:57 PM, Jim Thompson wrote: > > > >> On May 15, 2017, at 10:02 PM, Laz C. Peterson wrote: >> >> Is Openswan what is used for IPSec? > > Strongswan. > > > ___ > 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 tunnels on AT&T U-Verse
Hi Jim, > On May 14, 2017, at 6:38 PM, Jim Thompson wrote: >> 3. Create one or more P2s to make selectors for traffic inclusion and >> exclusion. Note there's a bug in PFSense, where if you do IPSec from not-LAN >> interfaces, the traffic to the firewall's IP gets stolen unless you manually >> hack the PHP file that generates the IPSec traffic selector configuration, >> to >> whitelist more interfaces. This prevents being able to do Ping, DNS, NTP, >> etc. >> all other services against the firewall on non-LAN if IPSec is on. Bad times >> right there. > > Additional details would be great here. Even better would be to open a bug > on redmine.pfsense.org with these additional details. > I did discuss this problem previously in the mailing list and forum. I was seeking some views on the topic, before I went forward with filing a defect, as IPSec traffic selectors are an area I don't profess to understand incredibly well, and I wasn't 100% sure I didn't miss something in my analysis, and didn't want to generate a bogus bug if so. I found this when creating a restricted LAN on the OPT1 port that was allowed to use IPSec when the LAN connected to the LAN port was not supposed to use IPSec. Basically, it's a DMZ network inside a house, walled off from the normal network, with a separate wireless SSID and separate Ethernet ports, which is then IPSec connected to a colo facility, w/ the PFSense IPSec on both ends. The issue happens here: https://github.com/pfsense/pfsense/blob/e470f72139ed54972465e653e27536687ce58b23/src/etc/inc/vpn.inc#L807 If you look at this code, it doesn't exempt all of the firewall's own IPs or at least Internal IPs from getting captured by the IPSec selectors for any tunnels. So management / admin traffic / other helpers to and from the firewall, like Ping, DNS, NTP, DHCP / SLAAC, etc. don't get through or don't get replies because only the LAN IP gets exempted when the UI Checkbox for bypass is checked and not all of the other interfaces (or specifically chosen interfaces... it only has a checkbox for LAN and not for any others). Also it's only exempting IPv4 so IPv6 will get broken even more than IPv4 will, if you're doing IKEv2 w/ IPv6 tunnels on top, which I use heavily in my case. I "fixed it" by hand-editing this file that generates the VPN setup to make more bypass exemptions, and promptly watching the issues stop happening after I added this hack. > Don’t know what you mean by “broad”, but it’s all (multiple) /24s here. It took quite some time, for example, to get ::/0 in IPv6 routing across my tunnel w/o malfunctions. And the same would apply using 0.0.0.0/0, and it was very critical to read and follow this document, and the logical equivalent behavior for IPv6, to the letter for it to work. Regarding when the issues hit exactly... it can happen if you aren't really careful to make sure that the selectors grabbing big swaths of IP space on one tunnel end, aren't carefully restricted to a narrow range of IP space on the other tunnel end. It's not saying PFSense did something wrong, but more that with the IPSec stuff, you have to be extremely judicious with the setup of the selectors, to prevent them from stealing unexpected traffic and sending it in the tunnel. If you make typos here or mess up, you can make your firewall unreachable (especially w/ the bypass issues I wrote about above), and have to come in from the console to roll things back if they aren't set up 100% perfectly. >> 10. Instead of the MOBIKE and DPD crap, keep the tunnel up, by using valid >> IPs >> on PFSense on other end of tunnel in the P2 auto-ping host entry. This will >> keep the IPSec up all the time and keep it from getting foobarred, unless >> the >> link itself has a gnarly outage, in which case you're down regardless. >> >> 11. On both the P1 and P2, lock down the list of KEX, Enc, and Auth >> algorithms >> to a single solid algorithm. If the negotiation screws up, it causes weird >> connection problems which you will damage your brain trying to debug. > > All of this is of interest, and deeply appreciated, but I’ve got an IPsec > connection between home and work that has been stable since … a couple years > ago. I have very reliably working connections now as well, but only after hacking on vpn.inc as described above, and only when MOBIKE, DPD, Rekey, are all disabled. Otherwise, in my case, when the tunnel times out due to rekey, MOBIKE, DPD, detecting drops or relocation of anything, the renegotiation that gets triggered seems to get stuck, and all the traffic going through the tunnel is getting blocked. It's surely possible the UVerse router was causing the brokenness. I can play with the settings some more on the cleaner Comcast connection to see if I can reproduce it again. I forgot to mention another item, in the last go-around, which seemed to prevent me from getting as many IPSec tunnels stuck, timeouts, etc.: I always
Re: [pfSense] IPSec tunnels on AT&T U-Verse
Hello, In the last few months, I did some extensive experiments with UVerse residential service with and without PFSense. Both general purpose and with IPSec tunnels to a colocation facility. The primary defect I identified in UVerse itself was related to their router prohibiting you from altering or editing its default break-everything-inbound IPv6 configuration. Inability to work around it and use non-proprietary routers without flowing through the brain damage caused by their router led to switching to Comcast service in my case. I can say that generally you won't hit MSS or MTU problems in UVerse because it doesn't do textbook PPPoE stuff to mangle the L2 frames like classic DSL does. Most of my issues were actually caused by IPSec or PFSense version of it. Here are some items I have never seen put together in one place for the most reliable PFSense IPSec configuration. This is mostly walking through the screens in PFSense's order in its UI. This is assembled partly via IPSec PFSense wiki official pages, partly through a LONG list of assorted forum posts across many years I read, and a whole ton of testing and essentially endless swearing at my terminal across several weeks of work. If there's a way to give this back to the documentation pages or to people doing QA or Dev I would love to do so also. Matthew. Advice: 0. Always enable the debug logs recommended by this page: https://doc.pfsense.org/index.php/IPsec_Troubleshooting "Logging for IPsec is configured at VPN > IPsec, Advanced Settings tab. The most useful logging settings for diagnosing tunnel issues with strongSwan on pfSense 2.2.x are: IKE SA, IKE Child SA, and Configuration Backend on Diag All others on Control" 1. Always set the KEX to IKEv2 if at all possible. It allows doing IPv4 and IPv6 on a single P1 with IPv4 outer IPs only. 2. Use IPv4 as the P1 transport version. For obvious reasons, most exterior networks are brain damaged and can't do IPv6. 3. Create one or more P2s to make selectors for traffic inclusion and exclusion. Note there's a bug in PFSense, where if you do IPSec from not-LAN interfaces, the traffic to the firewall's IP gets stolen unless you manually hack the PHP file that generates the IPSec traffic selector configuration, to whitelist more interfaces. This prevents being able to do Ping, DNS, NTP, etc. all other services against the firewall on non-LAN if IPSec is on. Bad times right there. 4. On whatever side of a tunnel has a dynamic IP, if any, always use "Distinguished Name" as the Identifier. If you don't, a whole series of heinously insane stuff happens, which greatly increases the difficulty for the VPN Daemons to find the right PSKs or other credentials for the tunnel, and you get weird auth and crypto failures that make no sense. Note: this DNS name doesn't actually have to be defined or valid. It's basically a magic string. But you could define them in a DNS zone somewhere if you felt like it. Set the non-dynamic end to Peer IP, or anything else, but that one works well for me. Make sure this, and all other settings, are appropriately reciprocal from each side or stuff blows up in weird ways. 5. Unfortunately, in my case, connections always blow up and drop traffic, if "Disable rekey" is not checked on the Initiator end. This is really bad because these things are really supposed to be rekeyed. But if you don't fix it, SSHes and other important items don't just politely die, they freeze up unexplicably and get jammed up in the IPSec state machines never to apparently return. 6. Generally, check "Responder Only" on the non-dynamic side of the tunnel or things blow up. 7. Perversely, completely disable MOBIKE, regardless if both ends are static IPs or one is dynamic or not. It can cause the state machine epic fails described in Step 5, the same way the rekeying can. 8. Perversely, completely disable DPD also. It will nuke connections if it loses a packet here or there, and they don't re-establish cleanly. Instead, they get caught in state-machine hell, same as described in 7 and 5. 9. Make 100% sure the Routes / Networks in the P2s are right, or the tunnels will disagree about what to send each other from each end. Bad things can happen if you try to do stuff like 0.0.0.0/0 routes, when using an IPv4 IPSec outer tunnel, if you aren't careful, as non-tunnel traffic can get stolen by the selectors. To prevent weird stuff like that, you have to make sure that the Local Subnet entries, on the "Client" or "Less Central / Non Core Network" side of the tunnel are right. Very carefully read this page if using really broad Masks on one, other, or both ends of tunnel: https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel 10. Instead of the MOBIKE and DPD crap, keep the tunnel up, by using valid IPs on PFSense on other end of tunnel in the P2 auto-ping host entry. This will keep the IPSec up all the time
Re: [pfSense] looking for silent and powerful pfsense hardware
On Tue, Mar 28, 2017 at 08:13:54AM -0400, Vick Khera wrote: > I would recommend at least a Xeon processor base system for that traffic. > Really, the limit is PPS; do you know what that would be? Any system using > a Xeon will not be silent. I use a pair of high end custom-built boxes at > my data center, and they can push this kind of traffic, though my usual > sustained is only in the 200Mbps range. > > The only silent systems I have are based on the Atom C2758 processor, and I > do not think those will handle a full gigabit connection at full speed. This isn't right, the SG-2440 can do it. Matthew ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] looking for silent and powerful pfsense hardware
On Tue, Mar 28, 2017 at 09:59:05AM +0300, Eero Volotinen wrote: > Hi List, > > Looking for pfsense hardware that can handle 1000M/1000M internet > connection with NAT. > > Any recommendations? It must be silent.. > > -- > Eero This model can do gigabit with line-rate 64-byte packets: https://store.pfsense.org/SG-2440/ If you don't need line-rate it's possible with some other units. Can you provide more specifics on the traffic mix? Matthew. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Requesting Advice on IPSec reliability issue
Hello,
I have been doing a lot of IPSec stuff from PFSense to PFSense (all with latest
stable code versions) lately. I have run into several different weird issues,
where I could use some input how these could be fixed, and/or worked around. I
tried to describe some of the issues in a forum post also, but at the time I
hadn't gotten as far with debugging this issue:
https://forum.pfsense.org/index.php?topic=127136.0 . Perhaps some defaults
could be adjusted in PFSense to make things more reliable for others as well?
1. charon's default packet retransmission timer is way too slow. Your IPsec
connection will lock up for many, many seconds and kill off TCPs, etc. riding
above it, and make you lose SSH and such. I would love to be able to change
these nice settings to fix it, but I can't find a way to put overrides into the
UI. Can I stash them in *.d directories somewhere in the filesystem where
PFSense wouldn't clobber the content instead?
https://wiki.strongswan.org/projects/1/wiki/Retransmission
charon.retransmit_tries
charon.retransmit_timeout
charon.retransmit_base
I think something like this would help a lot:
charon.retransmit_tries = 5
charon.retransmit_timeout = 2.0
charon.retransmit_base= 1.6
2. I have some questions about this magical IPSec setting: "Auto-exclude LAN
address" aka "autoexcludelanaddress" aka "noshuntlaninterfaces". I have found
several issues here.
a) The setting doesn't work right if you use OPT1 to run your special IPSec
network, which is completely walled off from the normal network, because it can
only does one specific interface (LAN). I can't figure out how to work around
it from the UI. Same as above... is there a *.d directory available or other
method?
b) The setting doesn't work right if you use IPv6, because it's hardcoded to
IPv4 only. To me that seems like a bug. This is especially problematic if you
use IKEv2 to run IPv4 and IPv6 P2s on your P1 for adding IPv6 to networks stuck
inside of IPv4. Any services like NTP, default DNS Resolver / Forwarder, etc.
are broken because the firewall's replies get sent into the enc0 device and not
back onto the LAN as expected.
Suspect code is located here:
https://github.com/pfsense/pfsense/blob/e470f72139ed54972465e653e27536687ce58b23/src/etc/inc/vpn.inc
Here is the part which is missing important parameters:
conn bypasslan
leftsubnet = {$lansa}/{$lansn}
rightsubnet = {$lansa}/{$lansn}
authby = never
type = passthrough
auto = route
3. I am getting problems where my IPSec traffic quits transmitting right after
socket session timeouts and rekeys. I had to set the Firewall Optimization to
Conservative in order to make the sockets stay open longer so the IPSec sockets
on 500/udp and 4500/udp would not get broken and lose traffic. It did seem to
help somewhat but now it's blowing up every time it rekeys the tunnel.
a) Since these VPN ports are secretly opened up to the world using special
auto-generated policies in the firewall rulechains, it seems like I can't make
custom rules with longer timeouts to steal back control of the traffic, so I
could apply a longer, effectively infinite custom session timeout on these
sockets.
b) For the loss of traffic after rekeys, at the moment I am still kind stumped.
I tried disabling MOBIKE and DPD as described in
https://forum.pfsense.org/index.php/topic,41617.0.html which made some
improvement despite how one would expect the opposite result.
I also tried the option to "Initiate IKEv2 reauthentication with a
make-before-break" but it didn't help. On the Initiator side I get really weird
stuff going on like this log below, and the timestamps are mere seconds before
my traffic quits working on the tunnel. There is a lot of packet timeouts,
right around the rekeying time, and no traffic can get through properly after
that without power-cycling the tunnel. I wanted to see if I should change some
other IPSec Advanced settings to take care of this, or if there was a way to
disable rekeying temporarily to see if the issue will stop happening, as that
apparently used to have an option but doesn't have one now. (Log below
signature.)
Thanks,
Matthew.
Mar 14 23:06:16 fw-01 charon: 14[KNL] creating rekey job for CHILD_SA
ESP/0xc66be176/TARGET_IP
Mar 14 23:06:16 fw-01 charon: 14[KNL] creating rekey job for CHILD_SA
ESP/0xc66be176/TARGET_IP
Mar 14 23:06:16 fw-01 charon: 15[IKE] establishing CHILD_SA con1{1}
Mar 14 23:06:16 fw-01 charon: 15[IKE] establishing CHILD_SA con1{1}
Mar 14 23:06:16 fw-01 charon: 15[ENC] generating CREATE_CHILD_SA request 12 [
N(REKEY_SA) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Mar 14 23:06:16 fw-01 charon: 15[ENC] generating CREATE_CHILD_SA
request 12 [ N(REKEY_SA) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Mar 14 23:06:16 fw-01 charon: 15[NET] sending packet: from INITIATOR_IP[500] to
TARGET_IP[500] (300 bytes)
Mar 14 23:06:16 fw-01 charon: 15[NET] sending packet: from
INITIATOR_IP[500] to
