Ah ah ah, it's very complex to common mortals as me :)
Perhaps it is mature the time to adopt, after many years, the *SIMPLE* implementation created by Maiko VE4KLM for JNOS2, applying it to our systems:
Configuration
When adding a 44 route, typically one uses something like this :
route add 44.0/8 encap a.b.c.d
But does that automatically add the two levels of firewalling that we are discussing here? If not, it does not seem very relevant. It is quite easy to make a configuration that basically works (especially when using RIP which makes route statements like the above unnecessary), but the point is that it is not secure against abuse by malicious people. That is why additional work is needed.
Rob
On 9/20/18 9:17 PM, Rob Janssen wrote:
Ah ah ah, it's very complex to common mortals as me :)
Perhaps it is mature the time to adopt, after many years, the *SIMPLE* implementation created by Maiko VE4KLM for JNOS2, applying it to our systems:
- Configuration
-------------
When adding a 44 route, typically one uses something like this :
route add 44.0/8 encap a.b.c.d
But does that automatically add the two levels of firewalling that we are discussing here? If not, it does not seem very relevant. It is quite easy to make a configuration that basically works (especially when using RIP which makes route statements like the above unnecessary), but the point is that it is not secure against abuse by malicious people. That is why additional work is needed.
Rob
About this last statement, it is true that any project must be continuously improved to challenge something.
Now beginning with the subject "beware of IPIP scanner..." I understand that (until a contrary proof) the use of IP-in-UDP is more 'resilient' than IO-in-IP per se, against the malicious, in general.
Everyone of us don't forget, on our projects, only the little rich parts of the globe, but consider the whole situations where many internet service providers block outgoing traffic originating from within their network IF the IP address is not from within their own allocation of numbers - meaning that IP packets having a source address of 44 will never make it out.
And then consider the new (poor) generation of home user, even IPIP will not work, since most home users are now behind a cheep consumer firewall or NAT router of some type.
About the RIP: if it is exposed to attacks, and if convenient, we can coming back to source the encap.txt or process it to source into the linux machine, i.e on the following format:
44.x.x.x/y via x.x.x.x. dev tunl0 proto 44 onlink window 840
and so on. All made by hourly or even on minutes by using cronjob or other kinda scrips :)
About the security there are several technical approach, what is the best? Perhaps one of them is that using the 'black lists' or by using the 'tcp deny' methods, etc, together with the basic firewalling... but :)
Hello, it is not my place to comment for the most par but I might comment with regards to the following statement:
On Sep 21, 2018, at 3:07 AM, Gustavo Ponza g.ponza@tin.it wrote:
And then consider the new (poor) generation of home user, even IPIP will not work, since most home users are now behind a cheep consumer firewall or NAT router of some type.
It it certainly true that many home users are now behind firewalls and “NAT” devices that cause issues with many tunneling protocols such as IPIP. It’s worthwhile to mention that for a majority of these people it is possible to fix this issue with a third party device such as Ubiquiti’s Edgerouter X. I have seen a number of threads about this so it is clear that a majority of the participants in this mailing list are aware of this solution. The issue is with those who utilize an ISP that uses “Carrier Grade NAT” (often just “CGNAT”). In this situation, the user will often have no control over the firewall or “NAT” appliance and therefore no way to allow IPIP (or otherwise) traffic to travel to their 44net router. I am surprised that these have not been a significant number of threads about this issue before especially as there appears to be no good solution (not to say that there are not any solutions).
Bryce Wilson, AS202313
Note about NAT and NAT related terms being in quotation marks: I have been informed several times that the version of NAT found on most consumer hardware is in fact not NAT (Network Address Translation) but Stateful PAT (Port Address Translation). I use NAT above because that is the term that the majority of people would be familiar with. I aim not to use terms that are technically correct but not understood by the reader.
On Fri, Sep 21, 2018 at 2:20 PM secret.memail.com@gmail.com wrote:
It it certainly true that many home users are now behind firewalls and “NAT” devices that cause issues with many tunneling protocols such as IPIP. It’s worthwhile to mention that for a majority of these people it is possible to fix this issue with a third party device such as Ubiquiti’s Edgerouter X. I have seen a number of threads about this so it is clear that a majority of the participants in this mailing list are aware of this solution. The issue is with those who utilize an ISP that uses “Carrier Grade NAT” (often just “CGNAT”). In this situation, the user will often have no control over the firewall or “NAT” appliance and therefore no way to allow IPIP (or otherwise) traffic to travel to their 44net router. I am surprised that these have not been a significant number of threads about this issue before especially as there appears to be no good solution (not to say that there are not any solutions).
Bryce Wilson, AS202313
Note about NAT and NAT related terms being in quotation marks: I have been informed several times that the version of NAT found on most consumer hardware is in fact not NAT (Network Address Translation) but Stateful PAT (Port Address Translation). I use NAT above because that is the term that the majority of people would be familiar with. I aim not to use terms that are technically correct but not understood by the reader.
I often wonder how many people outside of mobile providers are behind carrier grade NAT. At some point I suppose its inevitable for IPv4. I am hoping if providers implement that, they are are least offering IPv6 too.
As for our purposes behind carrier NAT, John K9VE proposed a solution. And its to buy a cheap VPS (virtual host) and have a 44net subnet brought to it by BGP. From there you could use Openvpn which is a stateless (continuous handshaking to keep the outside connection open) so you don't need to worry about protocol/port forwarding from your home connection to the VPS.
I don't think you are able to bring in more than one IP address (per connection) with openvpn though. Where with ipip you can specify something other than a /32 to tunnel to you. I am sure there are other open source stateless VPN packages that I don't know about though.
The other thing is BGP requires nothing less than a /24 so you might end up with an allocation to your VPS that is bigger than you really need. So a group approach might be best.
Openvpn can route whatever size subnet you want ;) But you will also need a subnet for the openvpn clients. That subnet can be rfc1918, but I would advise against that
Ruben - ON3RVH
On 21 Sep 2018, at 22:00, Steve L kb9mwr@gmail.com wrote:
On Fri, Sep 21, 2018 at 2:20 PM secret.memail.com@gmail.com wrote:
It it certainly true that many home users are now behind firewalls and “NAT” devices that cause issues with many tunneling protocols such as IPIP. It’s worthwhile to mention that for a majority of these people it is possible to fix this issue with a third party device such as Ubiquiti’s Edgerouter X. I have seen a number of threads about this so it is clear that a majority of the participants in this mailing list are aware of this solution. The issue is with those who utilize an ISP that uses “Carrier Grade NAT” (often just “CGNAT”). In this situation, the user will often have no control over the firewall or “NAT” appliance and therefore no way to allow IPIP (or otherwise) traffic to travel to their 44net router. I am surprised that these have not been a significant number of threads about this issue before especially as there appears to be no good solution (not to say that there are not any solutions).
Bryce Wilson, AS202313
Note about NAT and NAT related terms being in quotation marks: I have been informed several times that the version of NAT found on most consumer hardware is in fact not NAT (Network Address Translation) but Stateful PAT (Port Address Translation). I use NAT above because that is the term that the majority of people would be familiar with. I aim not to use terms that are technically correct but not understood by the reader.
I often wonder how many people outside of mobile providers are behind carrier grade NAT. At some point I suppose its inevitable for IPv4. I am hoping if providers implement that, they are are least offering IPv6 too.
As for our purposes behind carrier NAT, John K9VE proposed a solution. And its to buy a cheap VPS (virtual host) and have a 44net subnet brought to it by BGP. From there you could use Openvpn which is a stateless (continuous handshaking to keep the outside connection open) so you don't need to worry about protocol/port forwarding from your home connection to the VPS.
I don't think you are able to bring in more than one IP address (per connection) with openvpn though. Where with ipip you can specify something other than a /32 to tunnel to you. I am sure there are other open source stateless VPN packages that I don't know about though.
The other thing is BGP requires nothing less than a /24 so you might end up with an allocation to your VPS that is bigger than you really need. So a group approach might be best.
https://groups.io/g/net-44-vpn/wiki/home
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 22/09/18 05:57, Steve L wrote:
I often wonder how many people outside of mobile providers are behind carrier grade NAT. At some point I suppose its inevitable for IPv4. I am hoping if providers implement that, they are are least offering IPv6 too.
Depends where you are, I know people in some countries have struggles with CGN for as long as 15 years (someone in India comes to mind), and some fixed wireless ISPs were using it 10-15 years ago too.
As for our purposes behind carrier NAT, John K9VE proposed a solution. And its to buy a cheap VPS (virtual host) and have a 44net subnet brought to it by BGP. From there you could use Openvpn which is a stateless (continuous handshaking to keep the outside connection open) so you don't need to worry about protocol/port forwarding from your home connection to the VPS.
That would work, at the cost of suboptimal routing, but better than nothing.
I don't think you are able to bring in more than one IP address (per connection) with openvpn though. Where with ipip you can specify something other than a /32 to tunnel to you. I am sure there are other open source stateless VPN packages that I don't know about though.
Yes, you can, and with careful setup, that can be done on a connection by connection basis (based on the ID of the connecting system). I have done this in a commercial situation, mixing single IP endpoints with VPNs to remote subnets on the same OpenVPN server. Currently, I am routing a /29 (non amprnet) via OpenVPN to my LAN to get more public IPs.
The other thing is BGP requires nothing less than a /24 so you might end up with an allocation to your VPS that is bigger than you really need. So a group approach might be best.
Yes, that would be best.
As I said, however, the routing would be suboptimal, because you don't have the benefit of the ipip mesh that normal tunnel endpoints have. All traffic would have to be routed through the OpenVPN server. Choose your VPS host location carefully! Also, the VPS will need to be on the ipip mesh as well as directly connected.
On Sat, Sep 22, 2018 at 08:02:06AM +1000, Tony Langdon wrote:
As I said, however, the routing would be suboptimal, because you don't have the benefit of the ipip mesh that normal tunnel endpoints have. All traffic would have to be routed through the OpenVPN server. Choose your VPS host location carefully! Also, the VPS will need to be on the ipip mesh as well as directly connected.
It depends on what you want to communicate with. For other AMPRNet hosts on the IPIP mesh, clearly you want to be part of that mesh.
However, if you're just using AMPRNet in order to get your own dedicated IP address and your primary goal is to participate in the larger Internet, a VPN to a BGP-advertised VPS is likely to satisfy your wants.
I believe a significant number of people who have AMPRNet addresses and are BGP-connected really don't care much about communicating with other IPIP mesh-connected hosts; their interest is the rest of the Internet.
Since there's no way to capture flow data for these folks, we'll never know where their traffic is going. All we can do is guess from anecdotal data. - Brian
On 22/09/18 08:14, Brian Kantor wrote:
It depends on what you want to communicate with. For other AMPRNet hosts on the IPIP mesh, clearly you want to be part of that mesh.
However, if you're just using AMPRNet in order to get your own dedicated IP address and your primary goal is to participate in the larger Internet, a VPN to a BGP-advertised VPS is likely to satisfy your wants.
True, good point, and I am a case in point, my BGP connected subnet only hosts Internet facing services, mainly Echolink proxies. I've also added an Echolink conference or two, now that I'm not IP constrained anymore. I use IPIP tunneling at home to connect myself to the mesh, BGP on the VPS for service provision. I should setup an OpenVPN tunnel between the two just to improve the routing for my subnet to the server.
I believe a significant number of people who have AMPRNet addresses and are BGP-connected really don't care much about communicating with other IPIP mesh-connected hosts; their interest is the rest of the Internet.
Since there's no way to capture flow data for these folks, we'll never know where their traffic is going. All we can do is guess from anecdotal data.
Yeah, that would be hard to gather data without running a survey of all who have registered a directly connected subnet.
It depends on what you want to communicate with. For other AMPRNet hosts on the IPIP mesh, clearly you want to be part of that mesh.
However, if you're just using AMPRNet in order to get your own dedicated IP address and your primary goal is to participate in the larger Internet, a VPN to a BGP-advertised VPS is likely to satisfy your wants.
We would like to setup a VPS host that has an allocation advertised through BGP and also participates in the IPIP mesh. Is there a known VPS provider that provides a VPS that will also advertise your own IPs on decent connection at a reasonable price? I found a list somewhere (I think on the groups.io VPN page) but it was just a list and not really any ratings or feedback. Our clubs' repeater network is tunneled all over the place to get enough public IPs to work right for a number of repeaters doing Allstar, Echolink, and DMR. We'd like to simplify, expand, and increase the quality.
Thanks.
Jason
On 22/09/18 08:50, Jason McCormick wrote:
We would like to setup a VPS host that has an allocation advertised through BGP and also participates in the IPIP mesh. Is there a known VPS provider that provides a VPS that will also advertise your own IPs on decent connection at a reasonable price? I found a list somewhere (I think on the groups.io VPN page) but it was just a list and not really any ratings or feedback. Our clubs' repeater network is tunneled all over the place to get enough public IPs to work right for a number of repeaters doing Allstar, Echolink, and DMR. We'd like to simplify, expand, and increase the quality.
To me, the most important thing for you is topology. For best performance of VPN clients, you want the VPS to be topologically as close as possible (i.e. at least on the same continent) to your VPN clients, to shorten the "extra" leg the VPN adds. Obviously, you want a reliable provider that will announce the subnet on BGP for you, etc as well. I can't offer any suggestions there.
Being in Australia, I particularly notice suboptimal routing issues caused by tunnels, because most endpoint choices are on the other side of the world, adding at least 200mS RTT to the path (unless the destination was close to the other end of the tunnel). This was a problem when tunneling IPv6 years ago (I've been native IPv6 for 7 years now).
On Fri, Sep 21, 2018, 6:52 PM Jason McCormick jason@mfamily.org wrote:
We would like to setup a VPS host that has an allocation advertised through BGP and also participates in the IPIP mesh. Is there a known VPS provider that provides a VPS that will also advertise your own IPs on decent connection at a reasonable price? I found a list somewhere (I think on the groups.io VPN page) but it was just a list and not really any ratings or feedback. Our clubs' repeater network is tunneled all over the place to get enough public IPs to work right for a number of repeaters doing Allstar, Echolink, and DMR. We'd like to simplify, expand, and increase the quality.
Thanks.
Jason
I use Vultr and many others seem to as well. As cheap as $2.5/m and they'll BGP announce for you.
Someone on LowEndBox forums has put together a list at http://bgp.services if you'd like to shop around.
Regards,
Scott
-
Brian Kantor -
Gustavo Ponza -
Jason McCormick -
Rob Janssen -
Ruben ON3RVH -
Scott Nicholas -
secret.memail.com＠gmail.com -
Steve L -
Tony Langdon