Hi everyone,
Anyone been playing with GRE tunneling?
I am looking at that solution to bring part of my /24 to sites where I have multiple machine that each need a 44 address. GRE have no encryption, it is only an encapsulation of a Layer 2 packet. This lower the actual possible MTU size lowering the throughput slightly. But it is an easy way to connect a site to the VPS. At the same time, we dont need encryption as all the data that are passing into that tunnel is supposed to be ok to route on the internet. and if they contain special thing they should already be encrypted with tls/ssl or other mean of securing the connection.
Anyone have experience with this?
I would then use openvpn is its normal way for simple client. Then I imagine I will need to bridge both tunnel so that every one could talk to each other at the VPS level.
Sounds plausible?
Pierre VE2PF
Hi
I'd look in to wireguard as an alternative to GRE
Chris
On Fri, 4 Dec 2020, 17:03 pete M via 44Net, 44net@mailman.ampr.org wrote:
Hi everyone,
Anyone been playing with GRE tunneling?
I am looking at that solution to bring part of my /24 to sites where I have multiple machine that each need a 44 address. GRE have no encryption, it is only an encapsulation of a Layer 2 packet. This lower the actual possible MTU size lowering the throughput slightly. But it is an easy way to connect a site to the VPS. At the same time, we dont need encryption as all the data that are passing into that tunnel is supposed to be ok to route on the internet. and if they contain special thing they should already be encrypted with tls/ssl or other mean of securing the connection.
Anyone have experience with this?
I would then use openvpn is its normal way for simple client. Then I imagine I will need to bridge both tunnel so that every one could talk to each other at the VPS level.
Sounds plausible?
Pierre VE2PF _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
GRE works just fine depending on your system. We've never had any problems with GRE except using Mikrotik devices. There is a bug in the GRE implementation on MikroTiks where you will experience a 20-30% packet loss when the system is under any non-trivial use (e.g. multiple audio streams or a file transfer). Several versions of the OS and several different hardware platforms all experienced the same issue. We changed to IPIP and IPIP6 and the issue disappeared with no other reconfiguration. We're using a mix of IPIP, IPIP6, and GRE6 tunnels to a number of sites fed out of our VPS gateway.
For security, do your encryption at the protocol level. SSH, HTTPS, etc. will all ride over GRE just fine. IPSec is too complicated and messy. Wireguard is a nice option but just isn't there yet, especially with hardware devices.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of pete M via 44Net Sent: Friday, December 4, 2020 12:01 PM To: 44net@mailman.ampr.org Cc: pete M petem001@hotmail.com Subject: [44net] GRE tunnels
Hi everyone,
Anyone been playing with GRE tunneling?
I am looking at that solution to bring part of my /24 to sites where I have multiple machine that each need a 44 address. GRE have no encryption, it is only an encapsulation of a Layer 2 packet. This lower the actual possible MTU size lowering the throughput slightly. But it is an easy way to connect a site to the VPS. At the same time, we dont need encryption as all the data that are passing into that tunnel is supposed to be ok to route on the internet. and if they contain special thing they should already be encrypted with tls/ssl or other mean of securing the connection.
Anyone have experience with this?
I would then use openvpn is its normal way for simple client. Then I imagine I will need to bridge both tunnel so that every one could talk to each other at the VPS level.
Sounds plausible?
Pierre VE2PF _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi,
On 04/12/2020 17:00, pete M via 44Net wrote:
Anyone been playing with GRE tunneling?
The HamBSD sites, MB7VX and MB7UAR are linked via GRE/IPsec tunnels on OpenBSD. These links use encryption as they are passing over the public Internet, but if you wanted to run over amateur links you could use the setup I've described in my Internet Draft on carrying AX.25 traffic over IP using IPsec for authenticity guarantees (e.g. ensuring that only licensed amateurs can cause the radio to transmit):
https://tools.ietf.org/html/draft-learmonth-intarea-rfc1226-bis-02
Wireguard is not as flexible as IPSec when it comes to things like not having encryption but still keeping authentication.
Thanks, Iain.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 12/4/20 12:00 PM, pete M via 44Net wrote:
Anyone been playing with GRE tunneling?
Yes, this is a service I offer to anyone wanting to have a /29-/26 of the space I have, or they can bring their own and I'll announce it. I do this for two people now.
I am looking at that solution to bring part of my /24 to sites where I have multiple machine that each need a 44 address. GRE have no encryption, it is only an encapsulation of a Layer 2 packet. This lower the actual possible MTU size lowering the throughput slightly.
You want TCP-MSS clamping to fix this MTU issue when dealing with sites that block PMTUD.
But it is an easy way to connect a site to the VPS. At the same time, we dont need encryption as all the data that are passing into that tunnel is supposed to be ok to route on the internet. and if they contain special thing they should already be encrypted with tls/ssl or other mean of securing the connection.
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
Anyone have experience with this?
I use a cisco or linux box to do it. Super simple.
Cisco config below:
interface Tunnel73 description TUNNEL TO XXXXXX ip address 44.98.444.444 255.255.255.254 ip router isis ip nat outside ip virtual-reassembly in ip tcp adjust-mss 1436 clns mtu 1500 tunnel source vlan50 tunnel destination 69.69.69.69
73s - -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
1. copy the public keys from one host to the other
2. add one line to /etc/iked.conf with the IP addresses and the names for the public keys you copied in step 1
3. enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
1. copy the public keys from one host to the other
2. add one line to /etc/iked.conf with the IP addresses and the names for the public keys you copied in step 1
3. enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
copy the public keys from one host to the other
add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
- enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
A simple firewall rule to control the access into the IPIP or GRE endpoint should suffice. You don't want a wide-open IPIP/GRE listener, but narrowed down to the particular endpoint(s) you want to permit is very functional.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Marius Petrescu via 44Net Sent: Friday, December 4, 2020 3:56 PM To: pete M via 44Net 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] GRE tunnels
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
copy the public keys from one host to the other
add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
- enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
The same firewall rules can be used to protect pptp servers, strengthening the system.
But on the othe hand, the negotiation features of pptp offer dynamic routes on connect/disconnect, ip negotiation, subnet push and other goodies which are lacking in simple ipip or gre connections.
On 04.12.2020 22:58, Jason McCormick wrote:
A simple firewall rule to control the access into the IPIP or GRE endpoint should suffice. You don't want a wide-open IPIP/GRE listener, but narrowed down to the particular endpoint(s) you want to permit is very functional.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Marius Petrescu via 44Net Sent: Friday, December 4, 2020 3:56 PM To: pete M via 44Net 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] GRE tunnels
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
copy the public keys from one host to the other
add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
- enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi,
I would have thought that this community more than others would understand that BGP (especially for AMPR resources) is not all that secure, and IP addresses are not strong authentication.
It depends what you want to do though. If it's just for leisure and experimentation, then fine, you do not need encryption. If there are issues of abuse later, you can sort them out when they occur. For emergency communications, and also I guess because I come at amateur radio from a computing science background and not from a radio background, I prefer something a little more pro-active. I don't want to be finding that things have been randomly attacked (you don't need to be targeted to be attacked, look at ransomware it will just attack everything it can) mid-incident where you're trying to respond to some emergency and then your "resilient" communications turn out to be not so resilient.
There is no right or wrong answer, it depends on your threat model, but you should give it some critical thought. There's a reason that most roles in large enterprises will have training on IT security even if the role isn't even remotely IT related.
Thanks, Iain.
On 04/12/2020 20:58, Jason McCormick via 44Net wrote:
A simple firewall rule to control the access into the IPIP or GRE endpoint should suffice. You don't want a wide-open IPIP/GRE listener, but narrowed down to the particular endpoint(s) you want to permit is very functional.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Marius Petrescu via 44Net Sent: Friday, December 4, 2020 3:56 PM To: pete M via 44Net 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] GRE tunnels
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
copy the public keys from one host to the other
add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
- enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I never said it was "strong authentication", I said it "should suffice". I've been doing IT and security work for a long time so I chose my words carefully.
For the actual threat posed to an amateur radio IPIP or GRE tunnel, the effort to deploy, maintain and troubleshoot complex technologies like IPSEC - especially by those who are not networking experts - is not justified by the actual threat posed to the connection. Could an adversary work out a man-in-the-middle attack, misroute your traffic, and spoof one end of your IPIP/GRE tunnel? Sure. Is it in any way likely to happen? Not in in the least. If you've attracted the attention of a malicious actor who is capable and willing to do that against your connection, then doing a 44Net connection to begin with is probably the wrong strategy for whatever the workload is and you have bigger problems.
Increased security brings increased complexity. Yes, I can make a super-secure tunneled connection with PKI authentication, ephemeral keying, and all sorts of other things. But it's complex and largely unnecessary for the threat posed to some links used to cart around some digital voice traffic.
Is an authenticated and private (encrypted) tunnel better? Sure. Is it necessary? That's a harder question.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Iain R. Learmonth via 44Net Sent: Friday, December 4, 2020 4:11 PM To: 44net@mailman.ampr.org Cc: Iain R. Learmonth irl@hambsd.org Subject: Re: [44net] GRE tunnels
Hi,
I would have thought that this community more than others would understand that BGP (especially for AMPR resources) is not all that secure, and IP addresses are not strong authentication.
It depends what you want to do though. If it's just for leisure and experimentation, then fine, you do not need encryption. If there are issues of abuse later, you can sort them out when they occur. For emergency communications, and also I guess because I come at amateur radio from a computing science background and not from a radio background, I prefer something a little more pro-active. I don't want to be finding that things have been randomly attacked (you don't need to be targeted to be attacked, look at ransomware it will just attack everything it can) mid-incident where you're trying to respond to some emergency and then your "resilient" communications turn out to be not so resilient.
There is no right or wrong answer, it depends on your threat model, but you should give it some critical thought. There's a reason that most roles in large enterprises will have training on IT security even if the role isn't even remotely IT related.
Thanks, Iain.
On 04/12/2020 20:58, Jason McCormick via 44Net wrote:
A simple firewall rule to control the access into the IPIP or GRE endpoint should suffice. You don't want a wide-open IPIP/GRE listener, but narrowed down to the particular endpoint(s) you want to permit is very functional.
Jason
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Marius Petrescu via 44Net Sent: Friday, December 4, 2020 3:56 PM To: pete M via 44Net 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] GRE tunnels
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information in that setup. All the communication are for repeaters or device that will be used to monitor the site, remote control or such. So a simple tunnel without encryption is ok. But authentication is just plain obligatory.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Iain R. Learmonth via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 14:43 À : 44net@mailman.ampr.org Cc : Iain R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
This is perfectly fine and I'm not going to say you're wrong for doing it this way, but if you were building out something that could be used for emergency communication then it can pay to add authentication. You might also end up cornered into carrying potential personal information over your network (e.g. safety of life exemptions), and it'd be nice if you limited the scope of the interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
copy the public keys from one host to the other
add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
- enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to 44.190.21.234/32 local 44.190.21.1 srcid hambsd.org dstid mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR has redundant internet connections, and is behind a NAT on both, so the other end is not fixed) with the first two IP addresses as the "internal" tunnel IP addresses. The third IP address is where to listen "outside" the tunnel. The srcid and dstid just match up the public keys to make sure you're authenticated.
Thanks, Iain.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi, On 04/12/2020 20:55, Marius Petrescu via 44Net wrote:
In this case, why not use pptp? It does transport data over gre and offers a decent authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because of "shortcut" implementations done by MS, but still no exploit is out in the wild.
Exploit can be found at: https://www.willhackforsushi.com/?page_id=41 and it is over a decade old.
Thanks, Iain.
Yes, there is a way. Just that you need to have that key exchange capture available.
Which means access to a compromised system on the backbone or at the ISPs side, which also should allow you to do the capture.
And that is note quite trivial and an effort not justified for cracking of a puny 44net gateway access with no added benefits.
On the other hand, I understood that only specific implementations are actually vulnerable because of an implementation glitch where a key calculation is done just half the way offering a possibility to guess the password.
Whatever, the ease of management of such a system outperforms a plain gre tunnel and discourages access of script kiddies. Of course, a serious hacker could probably do it, but to what end?
I have such a system running for years, and apart from some sporadic login attempts with "root", "admin", "office", "sales" and such, and trying some dictionary passwords, nothing serious ever occurred.
Just my personal opinion,
Marius, YO2LOJ
On 04.12.2020 23:13, Iain R. Learmonth via 44Net wrote:
Exploit can be found at: https://www.willhackforsushi.com/?page_id=41 and it is over a decade old.
Thanks, Iain.
Thanks Bryan,
Looks like it will be the solution for my small sites. Do you confirm that if I set this up for a /29 they will have 6 address available cause they will use the first for the gateway and the last as the broadcast address of the /29? Do you set a DHCP server at the remote site usually?
Got a good How-to for a debian machine for the setup?
Pierre Ve2pf
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Bryan Fields via 44Net 44net@mailman.ampr.org Envoyé : 4 décembre 2020 13:55 À : 44net@mailman.ampr.org Cc : Bryan Fields Objet : Re: [44net] GRE tunnels
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 12/4/20 12:00 PM, pete M via 44Net wrote:
Anyone been playing with GRE tunneling?
Yes, this is a service I offer to anyone wanting to have a /29-/26 of the space I have, or they can bring their own and I'll announce it. I do this for two people now.
I am looking at that solution to bring part of my /24 to sites where I have multiple machine that each need a 44 address. GRE have no encryption, it is only an encapsulation of a Layer 2 packet. This lower the actual possible MTU size lowering the throughput slightly.
You want TCP-MSS clamping to fix this MTU issue when dealing with sites that block PMTUD.
But it is an easy way to connect a site to the VPS. At the same time, we dont need encryption as all the data that are passing into that tunnel is supposed to be ok to route on the internet. and if they contain special thing they should already be encrypted with tls/ssl or other mean of securing the connection.
I take the position that it's ham radio, I don't mess with IPSEC, just run GRE directly on the connection.
Anyone have experience with this?
I use a cisco or linux box to do it. Super simple.
Cisco config below:
interface Tunnel73 description TUNNEL TO XXXXXX ip address 44.98.444.444 255.255.255.254 ip router isis ip nat outside ip virtual-reassembly in ip tcp adjust-mss 1436 clns mtu 1500 tunnel source vlan50 tunnel destination 69.69.69.69
73s - -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Re-sending, not sure why mailman ate this.
On 12/4/20 2:47 PM, pete M via 44Net wrote:
Thanks Bryan,
Looks like it will be the solution for my small sites. Do you confirm that if I set this up for a /29 they will have 6 address available cause they will use the first for the gateway and the last as the broadcast address of the /29? Do you set a DHCP server at the remote site usually?
Got a good How-to for a debian machine for the setup?
Please send me an email offlist and I'll be happy to config it for you. Same goes for anyone else who wants it too.
73's - -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
-
Bryan Fields -
Chris Lawrence -
Iain R. Learmonth -
Jason McCormick -
Marius Petrescu -
pete M