> I can ping 44.153.32.97 from here and connect to his port 6300.
> - Brian
When I ping from a public IP it works, the traffic will then be routed over internet
to amprgw and then tunneled to him. He probably has reverse traffic via amprgw so there
is an open "session" in his router.
When he pings me, he gets replies. But when I later (or before) ping him, I only see
the traffic departing at our GW (properly encapsulated and sent to 181.192.58.28) but
nothing is returned.
I suspect it is the problem of being behind a stateful firewall in a NAT router. This
sometimes cannot be disabled for other protocols than TCP/UDP even when defining the
host as "DMZ Host". But I don't know if he has already tried that.
Rob
All,
FYI, I have recorded NetFlow on my tunl0 interface that appears to be
NESTED IPENENCAP packets. I have also seen these previously.
This is similar to a vector I described in my 20AUG remarks in
"Security/Wiki Question - Requesting a Block."
Because the source and destination IP addresses recorded could be
spoofed (or the result of a misconfigured AMPR router), I do not want to
alarm anyone by giving the specific address. I will note the packets
contained the source address of an AMPR node and the destination of
AMPRGW (i.e. another nested packet or a packet that would be
de-encapsulated by AMPRGW); and were recorded over 60 seconds in a
window of 24 hours. I have added the following rule to my firewall, to
appear in iptables before my bogons:
# THIS PREVENTS NESTED IPENCAP
iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP
To add: a source IP iptables rule (based on BCP 38) had prevented these
packets from forwarding.
73,
- Lynwood
KB3VWG
/"//Archives of security comments in this forum from others suggest
proper firewalling is necessary in environments running IPENCAP-enabled
routers, ESPECIALLY BECAUSE of the presence of NAT/masquerade
co-existing in some AMPRNet nodes..."/
> FYI, I have recorded NetFlow on my tunl0 interface that appears to be
> NESTED IPENENCAP packets. I have also seen these previously.
I have had a rule in place to log and drop these for ages, and I have not seen them
recently at our gateway. As pointed out, they are configuration errors, e.g. because
people put 44net addresses as tunnel endpoint address and policy routing is sending
the traffic into a tunnel instead of direct on the interface.
Other misconfigurations can result in recursive encapsulation. I believe I added the
rule when there was an incident resulting in many-level encapsulated IPIP packets that
only were limited by the MTU.
When you are worried about intrusions it is probably more effective to block IPIP
packets from sources that are not in the gateway list. I do that as well (via ampr-ripd).
Rob
> So in my opinion the best approach would be to send only traffic with 44
> origin and 44 destination not in other routes via ampr-gw, to preserve
> your original 44 IP.
> All the rest should be NAT-ed to your public gateway IP, not your
> gateway's 44 net, in order to circumvent the whole 44net completely.
> This will give you better speed, better response times and will ease the
> work of the ampr gateway.
I agree that there are situations where you better NAT the traffic than send
it via amprgw. E.g. you are running Windows or Linux systems on 44-net addresses
and you want to fetch operating system- or virus signature updates from an internet
source, and you do not want to needlessly load amprgw with that traffic.
(over here that does not really matter, we have our own gw and it can easily
handle that load for the subnet of users that are in 44.137.0.0/16)
Unfortunately, there are also situations where that NAT is really undesirable.
The best example is Echolink. It simply will not work correctly when your system
partly communicates directly (to other 44net systems) and partly uses NAT to
communicate to internet systems.
Of course it is also possible to use advanced techniques like the packet- and
connection marking that you already mentioned to run a mix between direct and NAT.
For a while I had a connection mark in the gateway that was set for certain
host/port combinations and forced the use of srcnat in the POSTROUTING table.
This was an attempt to work around issues like Echolink and also reachability
of a system that is also running partly with NAT. I have dropped it some time
ago as it was not easy to maintain it.
Rob
Hey all,
I've been trying to configure a Mikrotik router to allow devices
connectivity to the Amprnet and have been running into a bit of a snag.
First off here's what my architecture looks like:
Internet------------->Edge Router------------>AMPR
Mikrotik------------->Devices
I have a public IP on the edge router and a static /29 of public IPs
between the Edge router and the AMPRNet router. I have confirmed I have
external access to the AMPRNet router's public IP.
I followed the guide outlined by Marius here:
http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt and have the
following WORKING as expected:
1) connectivity from the Internet to my router's 44 IP (44.135.193.129)
2) connectivity to/from the AMPRNet to my router's 44 IP
3) connectivity to/from the AMPRNet to devices behind my router
(44.135.193.18)
What is not working is connectivity from the Internet to devices behind
the router; i.e. I am unable to PING these devices from the Internet and
am unable to access any Internet resources from these devices. If I add
a layer of NAT at the AMPR router, the end devices CAN access the
Internet, as the source IP is concealed and appears to UCSD to be that
of the 44 IP of my router (44.135.193.129).
I have also tried to add an additional 44 IP to my ampr-gw IPIP
interface (44.135.219.130/8) but am also unable to PING that IP from the
Internet. When I look at a packet capture on the router I do not see
any packets destined for this second IP making it to the router at all.
Is there something special that needs to be done in order to facilitate
routing to more then one 44 IP via the UCSD tunnel?
Cheers,
Chris
> if you want to go to the internet from 44net you need to NAT. you should
> also have a firewall to deal with those issues as well
> also you want to NAT if you go from a non-routable to 44net
This is of course incorrect. The whole point of having amprgw is to be able to
communicate between 44net and internet without having to use NAT.
But indeed it is true that for amprgw and some other gateways to transport your
traffic between internet and 44net you need to have a DNS entry for each of your
addresses. And it is also true that you should have a careful look at your
firewall when you are not used to having systems "directly on the internet"
without the implicit firewalling provided by a NAT router.
Rob
> Perhaps someone would like to know not only what are the callsigns under
> which both endpoints of the RF are operating, but also who is the
> Amateur that originated the message and which Amateur is the final
> recipient. I can imagine several reasons to want to know these.
In the packet radio days, our license conditions explicitly included this
requirement. It was fulfilled by ordinary digipeating, but not by NET/ROM.
I added support to my version of NET to make NET/ROM nodes operate as a
virtual digipeater, so the outgoing connect of a NET/ROM on behalf of a
user was not made under the USERCALL-(15-SSID) call, but as "user via node".
(a packet that was transmitted by the node as if it had been digipeated
by the node)
IP was a problem under those regulations, however an arrangement was made
with the authorities that source and destination of the traffic were
sufficiently identified when there was an accessible list of IP addresses
and corresponding callsigns. The hosts files provided that information.
(I doubt that the authorities ever listened in on amateur IP over AX.25
traffic and tried to identify the endpoints, I heard that the only AX.25
equipment available at the monitoring station was a PK-232)
However, since then we have lost our "license" and now operate under a
"unlicensed station with mandatory registration" regime here, with usage
conditions that are far less detailed. Operating modes are no longer
specified, only identification modes. As long as you ID your station in
one of a specified set of modes, they no longer care what you transmit
and what its source is.
This also makes it legal to forward internet content, something that was
not allowed under our old license conditions (that explicitly prohibited
3rd party content and connections with external networks).
But of course it can still be useful to have identification information
in IPv6 addresses, if only because of the general lack of reverse-DNS
information in the IPv6 network.
Rob
> I don't see why anyone would want to encode information about the
> country in the first 64 bits, especially since you can use compound
> callsigns such as PA/EA4GPZ if you're operating abroad.
> Perhaps it would be interesting to have the information about the
> Maidenhead locator or GPS coordinates of a subnet (where this makes
> sense). Someone could use this info to make a geographical map of the
> network. However, I think that this info should belong to an external
> database (whois maybe) and not be encoded in the IPv6's.
I also don't think it should be done that way, especially because we seem to agree
on the idea that we do not want to have a large IPv6 network for amprnet (which we
could subnet in creative ways), but rather use the IPv6 addresses provided by a
local ISP. We don't have control over the numbering and network size of those
addresses, and especially during the initial phase of the rollout there will always
be ISPs that do not understand IPv6 and give a customer only a single /64 or even
less. Hopefully that will change later, but we cannot wait for that forever.
So, keep all special handling in the last 64 bits and treat the first 64 as random.
I think a special handling of the address should not even be mandatory, only a
good suggestion that may help others to determine the source of traffic easily.
It should still be possible to send traffic from addresses not conforming to this
methid, at most risking that it will be dropped at an internet-radio gateway when
prior arrangements have not been made.
Probably a next step would be to standardize a method to distribute information
about valid IPv6 AMPRnet networks (that can be somewhat trusted in access lists).
E.g. use BGP, downloadable textfiles, (ampr-)RIPv6, etc. It may not be possible
to standardize a single method due to limitations of used software and hardware,
although this probably is less important than with the current gateway list.
(where we need to remain compatible with very old software that cannot do IPv6 anyway)
Rob
> Hmm.. Do you have any examples of such ISPs? I’ve only seen them give out a /64 to the PPPoE / WAN interface and then also have a routable /56 or /48 which is almost always available using DHCPv6-PD. The /64 is only used for communication with the ISP (can also be a /126) while everything else if up to the router to manage.
Although I do get a /48 from my ISP there is nothing I can manage about the subnetting. The 16 bits between my prefix and my networks are
assigned by my router using DHCPv6-PD and there is nothing I can do to set these bits. They are assigned to my networks sequentially.
I don't think it is feasible to use those bits with a special meaning.
Rob
