Re: SSL VPN
+1and it also support HA. Sent from my Samsung Galaxy smartphone. Original message From: Mark Tinka Date: 13/06/2019 14:59 (GMT-03:00) To: nanog@nanog.org Subject: Re: SSL VPN On 1/Jun/19 16:53, Mehmet Akcin wrote:> Hey there>> I am trying to choose SSL VPN for a remote office 3-4 people max each> any given time.>> I have looked at Pulse and Cisco, and wanted to check in here for> recommendations on latest trends.>> Trying to get a solution easy to manage and won’t break the bank with> licenses when team grows to 10.>> Thanks in advance.OpenVPN in pfSense?We run tons of these around the world.Mark.
Re: someone is using my AS number
On Thu, Jun 13, 2019 at 09:58:20AM -0400, Joe Abley wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > > However, there's an argument that AS_PATH is really just a > loop-avoidance mechanism, not some kind of AS-granular traceroute > for prefix propagation. In that sense, stuffing 9327 into a prefix > as a mechanism to stop that prefix being accepted by AS 9327 seems > almost reasonable. (I assume this is the kind of TE you are talking > about.) > > What is the principal harm of doing this? Honest question. I'm > not advocating for anything, just curious. There is no way at a distance to tell the difference between: - legitimate AS forwarding - ham-fistedly attempting "innocent" TE away from the forged AS - maliciously hiding traffic from the forged AS - an error with the forged AS IME, when you can NOT look like an error or an attack, that's a Good Thing. The last "major" provider who failed to provide BGP community-based TE was 3549, and with their absorbtion into 3356 no one should have any tolerance for this garbage, IMNSHO. Cheers, joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
Re: SSL VPN
On Thu, Jun 13, 2019 at 6:12 PM Eric Tykwinski wrote: > This is the second time I’ve seen WireGuard this past week, and honestly > sounds really promising. > I’m probably going to test out on VyOS since I know it has support, but > any word on ASA or JunOS? > I.E. is this going to export to hardware since it’s in the kernel already? > The kernel? Which kernel? Given that neither Cisco nor Juniper ever adopted support for running OpenVPN on their platforms, I suspect it's unlikely that they'd adopt support for Wireguard. I would venture that as far as appliance support, the best bet is likely to be NetGate and pfSense, but I think Wireguard is going to have to come out with an "OK, we're comfortable with being considered production-ready" statement first, given that the front page of their website right now still proclaims the opposite. Once that happens - and the ball is largely in Wireguard's court to move that forward - then we should expect to see more mainstream adoption into products like pfSense.
Re: SSL VPN
> On Jun 13, 2019, at 2:32 PM, Randy Bush wrote: > >> OpenVPN in pfSense? > > yep > >> We run tons of these around the world. > > i only do 0.5kg > > wireguard, https://www.wireguard.com/, is simpler (always a good thing > with security), and has had code looked at by some credible experts. > This is the second time I’ve seen WireGuard this past week, and honestly sounds really promising. I’m probably going to test out on VyOS since I know it has support, but any word on ASA or JunOS? I.E. is this going to export to hardware since it’s in the kernel already? > randy
Re: SSL VPN
> OpenVPN in pfSense? yep > We run tons of these around the world. i only do 0.5kg wireguard, https://www.wireguard.com/, is simpler (always a good thing with security), and has had code looked at by some credible experts. randy
Re: SSL VPN
On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka wrote: > > OpenVPN in pfSense? > > We run tons of these around the world. > > Mark. > > With the client config generator package, "openvpn-client-export", installed, this is imho the best option for an end-user VPN. pfSense has a much nicer UI than OpenVPN AS, and that UI also supports other things you might need (like routing protocols via bird or quagga, managing the firewall, etc) as well. I can't see any reason to pay money for OpenVPN AS when you compare it to what you get for free with pfSense. The NetGate pfSense appliances are quite nicely spec'd, too, if you just have cash burning a hole in your pocket. It also easily ties in OpenVPN authentication to RADIUS or LDAP, and getting it working with Active Directory on the backend is trivially simple.
Re: SSL VPN
On 1/Jun/19 16:53, Mehmet Akcin wrote: > Hey there > > I am trying to choose SSL VPN for a remote office 3-4 people max each > any given time. > > I have looked at Pulse and Cisco, and wanted to check in here for > recommendations on latest trends. > > Trying to get a solution easy to manage and won’t break the bank with > licenses when team grows to 10. > > Thanks in advance. OpenVPN in pfSense? We run tons of these around the world. Mark.
Re: someone is using my AS number
other than the possibility of the stuffed AS being associated with behavior, no harm if nothing malicious is happening. if something malicious is happening, we probably have bigger problems. have used path poisoning for a notable research experiment; where we credit the first major poisoner, lorenzo's thesis. randy
Re: someone is using my AS number
On Thu, Jun 13, 2019 at 11:37 AM Jared Mauch wrote: > > You also may not know who allows their own ASN inbound as well. It certainly > is a mixed bag. > > I do consider poisoning at best horrible hygiene and at worst evidence of > malicious intent. Yes, I fully agree it it bletcherous -- which is why I'm looking for something less ugly... > > Good filtering isn’t just prefix or AS path based it’s both. > > Best filtering is pinning the prefix to a specific ASN. > > Sent from my iCar > > On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: > > On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: >> >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" was >> > > never a good idea. Sharing the affected prefix[es]/path[s] would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other peoples' AS >> > numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer >> routes, any time a packet touches ISP_X, it goes to this location, >> even though it is (severely) suboptimal -- things would be better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in this >> location to not announce it to ISP_X. That's what communities / the >> telephone were invented for!" doesn't work for various (entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct customer >> instead of being a customer of a customer" or "disable that site", or >> "convince the AS upstream of you to deploy communities / filters"). >> While icky, sometimes stuffing other people's AS in the path seems to >> be the only solution... > > > > Given the prevalence of peerlock-style filters at the transit-free club, > poisoning the path may result in a large outage for your prefix rather than a > clever optimization. Er, let me think about this -- if I have 3 locations, A, B, and C, and at location A (the problematic one) I announce prefix 192.0.2.0/24 with ISP_X in the path, and at locations B and C I just prepend my AS# (to keep path lengths roughly the same), even if ISP_X, ISP_Y, ISP_Z (and others) enable peerlock, AFAICT, it will only be location A which might get filtered, yes? > Poisoning paths is bad for all parties involved. Not disagreeing - I'd love to tag my routes with community 1234:, or 1233:, but without useful levers, what do I pull? Unlike normally, I'm not arguing just for the sake of arguing, I'm a lookin' for suggestions... W > > Kind regards, > > Job -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: someone is using my AS number
I don't think the number of networks with disabled loop prevention is that small. For example, let's say you're a hosting provider who has 3 locations... no reason to do cold potato routing and you don't have dedicated links between sites, yet you still want ranges announced at DC A to be reachable from DC B and C. Kind Regards, Filip On 13 June 2019 5:56:16 pm GMT+02:00, Jon Lewis wrote: >I've used it in the distant past for TE purposes. Assuming you're >poisoning one ASN via one transit it's not exactly rocket science to >figure out if "it worked" or not. As Warren mentioned, sometimes your >transits just don't provide all the knobs you need. > >I suspect the number of networks that have intentionally disabled loop >prevention is relatively small, and those more likely "end user'ish" >networks that are less likely to be the target of as-path poisoning >TE...says the guy who just disabled loop prevention on a bunch of >routers. >:) > >On Thu, 13 Jun 2019, Jared Mauch wrote: > >> You also may not know who allows their own ASN inbound as well. It >certainly is a mixed bag. >> I do consider poisoning at best horrible hygiene and at worst >evidence of malicious intent. >> >> Good filtering isn’t just prefix or AS path based it’s both. >> >> Best filtering is pinning the prefix to a specific ASN. >> >> Sent from my iCar >> >> On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: >> >> On Thu, Jun 13, 2019 at 11:18 Warren Kumari >wrote: >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley >wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo > wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via >NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" >was >> > > never a good idea. Sharing the affected prefix[es]/path[s] >would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other >peoples' AS numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a >while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers >customer >> routes, any time a packet touches ISP_X, it goes to this >location, >> even though it is (severely) suboptimal -- things would be >better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in >this >> location to not announce it to ISP_X. That's what communities / >the >> telephone were invented for!" doesn't work for various >(entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct >customer >> instead of being a customer of a customer" or "disable that >site", or >> "convince the AS upstream of you to deploy communities / >filters"). >> While icky, sometimes stuffing other people's AS in the path >seems to >> be the only solution... >> >> >> >> Given the prevalence of peerlock-style filters at the transit-free >club, poisoning the path may result in a large outage for your prefix >rather than >> a clever optimization. Poisoning paths is bad for all parties >involved. >> >> Kind regards, >> >> Job >> >> >> > >-- > Jon Lewis, MCP :) | I route > | therefore you are >_ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: someone is using my AS number
I've used it in the distant past for TE purposes. Assuming you're poisoning one ASN via one transit it's not exactly rocket science to figure out if "it worked" or not. As Warren mentioned, sometimes your transits just don't provide all the knobs you need. I suspect the number of networks that have intentionally disabled loop prevention is relatively small, and those more likely "end user'ish" networks that are less likely to be the target of as-path poisoning TE...says the guy who just disabled loop prevention on a bunch of routers. :) On Thu, 13 Jun 2019, Jared Mauch wrote: You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag. I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent. Good filtering isn’t just prefix or AS path based it’s both. Best filtering is pinning the prefix to a specific ASN. Sent from my iCar On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > Actually, I've been meaning to start a thread on this for a while. I have an anycast prefix - at one location I'm a customer of a customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer routes, any time a packet touches ISP_X, it goes to this location, even though it is (severely) suboptimal -- things would be better if ISP_X didn't accept this route in this location. Now, the obvious answer of "well, just ask your provider in this location to not announce it to ISP_X. That's what communities / the telephone were invented for!" doesn't work for various (entirely non-technical) reasons... Other than doing path-poisoning can anyone think of a way to accomplish what I want? (modulo the "just become a direct customer instead of being a customer of a customer" or "disable that site", or "convince the AS upstream of you to deploy communities / filters"). While icky, sometimes stuffing other people's AS in the path seems to be the only solution... Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved. Kind regards, Job -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: someone is using my AS number
You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag. I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent. Good filtering isn’t just prefix or AS path based it’s both. Best filtering is pinning the prefix to a specific ASN. Sent from my iCar > On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: > >> On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" was >> > > never a good idea. Sharing the affected prefix[es]/path[s] would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other peoples' AS >> > numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer >> routes, any time a packet touches ISP_X, it goes to this location, >> even though it is (severely) suboptimal -- things would be better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in this >> location to not announce it to ISP_X. That's what communities / the >> telephone were invented for!" doesn't work for various (entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct customer >> instead of being a customer of a customer" or "disable that site", or >> "convince the AS upstream of you to deploy communities / filters"). >> While icky, sometimes stuffing other people's AS in the path seems to >> be the only solution... > > > Given the prevalence of peerlock-style filters at the transit-free club, > poisoning the path may result in a large outage for your prefix rather than a > clever optimization. Poisoning paths is bad for all parties involved. > > Kind regards, > > Job
Re: someone is using my AS number
On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > > > Hey Joe, > > > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > > >> Send abuse complaint to the upstreams > > > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > > never a good idea. Sharing the affected prefix[es]/path[s] would > > > be good. > > > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > > > > Actually, I've been meaning to start a thread on this for a while. > > I have an anycast prefix - at one location I'm a customer of a > customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer > routes, any time a packet touches ISP_X, it goes to this location, > even though it is (severely) suboptimal -- things would be better if > ISP_X didn't accept this route in this location. > > Now, the obvious answer of "well, just ask your provider in this > location to not announce it to ISP_X. That's what communities / the > telephone were invented for!" doesn't work for various (entirely > non-technical) reasons... > > Other than doing path-poisoning can anyone think of a way to > accomplish what I want? (modulo the "just become a direct customer > instead of being a customer of a customer" or "disable that site", or > "convince the AS upstream of you to deploy communities / filters"). > While icky, sometimes stuffing other people's AS in the path seems to > be the only solution... Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved. Kind regards, Job
Re: someone is using my AS number
On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > Actually, I've been meaning to start a thread on this for a while. I have an anycast prefix - at one location I'm a customer of a customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer routes, any time a packet touches ISP_X, it goes to this location, even though it is (severely) suboptimal -- things would be better if ISP_X didn't accept this route in this location. Now, the obvious answer of "well, just ask your provider in this location to not announce it to ISP_X. That's what communities / the telephone were invented for!" doesn't work for various (entirely non-technical) reasons... Other than doing path-poisoning can anyone think of a way to accomplish what I want? (modulo the "just become a direct customer instead of being a customer of a customer" or "disable that site", or "convince the AS upstream of you to deploy communities / filters"). While icky, sometimes stuffing other people's AS in the path seems to be the only solution... W > However, there's an argument that AS_PATH is really just a loop-avoidance > mechanism, not some kind of AS-granular traceroute for prefix propagation. In > that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix > being accepted by AS 9327 seems almost reasonable. (I assume this is the kind > of TE you are talking about.) > > What is the principal harm of doing this? Honest question. I'm not advocating > for anything, just curious. > > > Joe > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: someone is using my AS number
On 13 Jun 2019, at 10:06, Job Snijders wrote: > 1/ We can’t really expect on the loop detection to work that way at the > “jacked” side. So if this is innocent traffic engineering, it is unreliable > at best. > > 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get > blamed for anything that happens through the IP addresses for that route. In > a way the ASNs in the AS_PATH attribute an an inter-organizational escalation > flowchart. Good answer! Somebody should write that down. :-) Joe signature.asc Description: Message signed with OpenPGP
Re: someone is using my AS number
Hi Joe, On Thu, Jun 13, 2019 at 9:59 Joe Abley wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > > However, there's an argument that AS_PATH is really just a loop-avoidance > mechanism, not some kind of AS-granular traceroute for prefix propagation. > In that sense, stuffing 9327 into a prefix as a mechanism to stop that > prefix being accepted by AS 9327 seems almost reasonable. (I assume this is > the kind of TE you are talking about.) > > What is the principal harm of doing this? Honest question. I'm not > advocating for anything, just curious. Excellent question. 1/ We can’t really expect on the loop detection to work that way at the “jacked” side. So if this is innocent traffic engineering, it is unreliable at best. 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get blamed for anything that happens through the IP addresses for that route. In a way the ASNs in the AS_PATH attribute an an inter-organizational escalation flowchart. Kind regards, Job
Re: someone is using my AS number
Hey Joe, On 12 Jun 2019, at 12:37, Joe Provo wrote: > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: >> Send abuse complaint to the upstreams > > ...and then name & shame publicly. AS-path forgery "for TE" was > never a good idea. Sharing the affected prefix[es]/path[s] would > be good. I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. However, there's an argument that AS_PATH is really just a loop-avoidance mechanism, not some kind of AS-granular traceroute for prefix propagation. In that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix being accepted by AS 9327 seems almost reasonable. (I assume this is the kind of TE you are talking about.) What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. Joe signature.asc Description: Message signed with OpenPGP
