4 Dec
2020
4 Dec
'20
3:03 p.m.
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(a)mailman.ampr.org> On Behalf Of Marius
Petrescu via 44Net
Sent: Friday, December 4, 2020 3:56 PM
To: pete M via 44Net <44net(a)mailman.ampr.org>
Cc: Marius Petrescu <marius(a)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(a)mailman.ampr.org> de la part de Iain
R. Learmonth via 44Net <44net(a)mailman.ampr.org>
Envoyé : 4 décembre 2020 14:43
À : 44net(a)mailman.ampr.org
Cc : Iain R. Learmonth
Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 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.
--
https://hambsd.org/
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net