Brian K.:
*"This is precisely the situation that our longstanding method of tunnel
gateways is designed to overcome.
You do this by setting up a Linux host that is assigned a single PSU
address, probably something that isn't too hard to do. You shouldn't need
to have them open any holes in the firewall or ask for special treatment
as long as the existing firewall allows IPIP (internet protocol #4)
through, which most do because the firewall managers never thought to
block it, and also because some VPN schemes used to use it.
The PSU folks don't have to do anything about network 44 routing or BGP
or whatever.
You then get a subnet allocation from your regional AMPRNet IP address
coordinator and register a gateway for that subnet (via the PSU address)
on the portal. Voila', you now have a subnet of AMPRNet routed to your
Linux host via IP-IP encapsulation, and through the technique of tunnel
gatewaying that Linux host is now connected to the AMPRNet, albeit at
a somewhat limited bandwidth."*
*
*
I am not opposed to this, especially since I have not tried it yet.
However, PSU has resources, that if they can be tapped, might enable PSARC
do something equivalant to what USC is doing, but for the state of
Pennsylvania. For one, to further experiment, and also to improve the
bandwidth limitations down the road.
The 'Backbone" connection I expect to get through PSU will be 1
gigabit/sec. If co-located w/ PennREN, we would be sitting on a statewide
10Gb/s middle mile network. And, that is IPv6 now.
It would be a heck of a way to learn!
73, Jim A.
Jim,
Your question sounds similar to one I just asked last week. In my
case, convincing the IT department to forward IPIP to our internal
address isn't likely.
So I have been playing with OpenVpn, and started documenting things.
It looks like it will do what I want. Requests will come to my IPIP
Rip gateway, which will also double as an OpenVPN server, and I'll
route the traffic though that statefull connection.
I have been trying to track down notes/papers/documents that might be of use:
http://www.qsl.net/k/kb9mwr//wapr/tcpip/index.html
Speaking of which, does anyone else have any recommendations on things
that have been written over the years?
I swear I am the only ham in my local club that has at least a basic
understanding of TCP/IP. So anything I can use to help explain things
to newbies would be helpful. I usually just reference the O'Reilly
Books, TCP/IP Administration comes to mind.
Has anything ever been written explaining DNS records with a ham slant?
A gateway had his internet address change yesterday and the new address was
changed to the new address at the gateway successfully..
We've noticed that the RIP process has the correct address but the
encap.txt file does not.
Is there a problem at the gateway with the way it is handling the encap.txt
file when data is changed? It appears that the old file is sent and not
the new one..
73, Don - ve3zda
Excellent explanation Marius.
So how does PPTP compare to openvpn?
I have tried to find a good explanation for the various VPN types,
hamachi, openvpn, pptp, etc.. haven't really found such yet.
C.J. thanks for the examples. I think I know the answer to what I am going
to ask, but..
Could an IPIP tunnel accomplish the same thing that OpenVPN can for the
situation I described (NAT and no modification to a remote firewall)?
Why not?
Hello,
I have tried on a number of occasions to register on the Portal. I
have not received a confirmation email once.
Anyone else having this issue?
Thanks,
Geoff
VA7CWD / VE7KA
I am running a gateway using rip, etc. I really only have wifi radio range
to a couple other hosts. And that is working well.
We have a couple other small wireless networks in town that I can't reach
by radio. They could be connected to the internet but unfortunately would
be behind firewalls that we cannot control.
So till we get things realigned and such, I am looking for examples on how
to create a private tunnel from my gateway to those locations.
It doesn't really make sense to put another gateway in the portal, as I
doubt the rip packets will pass though.
Yes the separate clusters each have separate NAT/firewalls protecting them.
Again, I am not going to be able to convince the people donating that
bandwidth to set our internal ip on their network as a DMZ host.
I plan to write about it, if I ever figure out how to punch a two way
tunnel from me (a place where I have control over such things) to these
places.
What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here
via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from
here via some other capable tunnel to these remote sites till we convince
folks we need to get something up on a decent tower.
It doesn't need to be encrypted or authenticated, whatever is easiest and
will do the job.
--Quote--
I'm unclear on the topology of your network; I'm going to assume that
the separate clusters each have a separate NAT/firewall protecting them.
In that case, I believe you may get the IPIP traffic to pass through the
NAT/firewall to the internal host by designating the internal host as a
DMZ host. You would then register the NAT/firewall's public IP address
as the gateway host.
I'd wager it depends on the software in the NAT/firewall so some may do it
and others may not. I heard that OpenWRT does handle IPIP encapsulation.
I've not tried that myself so others who have done so should comment on
whether this approach actually works.
I'd much appreciate you writing up what you wind up doing and publish
it on the wiki so others may share your experience.
- Brian
First off I don't claim to know much about VPNs and encapsulation.
Everyone I talk to tells me openvpn should do what I want.
I take it that is a state full type of connection?
Brian, the problem I see if if I setup another rip44 listener gateway, how do I
direct the encapped traffic to our natted, internal IP? An entry in the portal
will get it to their router (outside address), but having them place a
forwarding rule to get it from there to out 192 internet address probably won't
happen.
---- Quote------
On Wed, Apr 17, 2013 at 12:38:01AM -0500, kb9mwr at gmail.com
<http://hamradio.ucsd.edu/mailman/listinfo/44net> wrote:
>* It doesn't really make sense to put another gateway in the portal, as I*>* doubt the rip packets will pass though.*
The AMPRNet internal RIP packets from 'amprgw' are sent encapsulated,
so if you can do IP-IP tunnels at all, the RIP should get through too.
One way to see whether a firewall will pass IP-IP tunnels is to add
its address as a gateway and see if you get tunnel traffic on the other
side. Since the internal RIP is sent every 5 minutes, it can be a simple
test of your incoming connectivity.
- Brian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good morning,
I saw some odd routing during my tests. So I analyzed the routes added
by RIP44d. I modified the code to log the command string to add
routes, my suspicions where confirmed: rip44d v1.2 adds every route
with a prefix length of /32:
(examples)
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44
All these routes should be /16
I'm trying to figure where the issue comes from, but I'm not a perl
addict, so any help is welcome. I have already confirmed that the RIP
message contains the correct netmask:
IP Address: 44.161.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.161.0.0 (44.161.0.0)
Netmask: 255.255.0.0 (255.255.0.0)
Next Hop: 141.75.245.225 (141.75.245.225)
Metric: 1
73 de Marc
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw
BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN
quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV
y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z
HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS
3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4
UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M
r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz
zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi
yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD
2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9
x6fcW9WXhFYoLN56hrti
=0CVp
-----END PGP SIGNATURE-----
