> For years, my node had similar behavior, causing various kinds of
> intermittent issues. The problem was solved when I added an iptables
> rule permitting inbound IPENCAP:
Ok in your case it was a configuration error?
Of course we should make sure that there is no error outside the router, e.g. by using
wireshark to confirm that IPIP packets are not arriving when the source is new.
Well, it will be a tricky investigation especially when we have to instruct those that
are not so proficient in networking to determine the cause of the problem.
(gateway system, internet router, maybe ISP filters or cgNAT)
Rob
> No, it is not ok.
> It is working because of connection tracking if YOU access the page.
> Here the output ofhttp://yo2tm.ampr.org/nettools.php ping:
> Ping Output:
> PING 44.153.32.97 (44.153.32.97) 56(84) bytes of data.
> --- 44.153.32.97 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms
Indeed, it is not working correctly.
He sent me a mail telling me that he could ping me at 44.137.41.97 and I happened to be
at the computer when it came in, I immediatelu tried to ping back and it worked.
Then I waited an hour, tried again, and again it did not work.
So all symptoms point to a stateful firewall of IPIP traffic, probably in his ISP router.
I suspect that some NAT routers do a connection tracking firewall even when the DMZ HOST
is set in the config. The DMZ HOST only receives all TCP and UDP traffic, but not protocol-4.
However, just like all other hosts on the LAN, it can send out protocol-4 traffic and
receive the "reply" traffic. So doing outbound connections works, but inbound on an
idle tunnel is not working.
It would be interesting to investigate which routers suffer from this bug, so a list can
be made on the WiKi page. I think quite some gateway stations have this fault.
The operator believes he has a working gateway because he can connect whatever other
gateway station he tries, but incoming connects do not work when there has been no
prior traffic.
(of course the same thing happens when DMZ HOST is not set at all, so this has to be
properly investigated)
Rob
Hello !! as I can test the ping to my ip ..
my route in dmz activated addressed to my pc
I tried the page http://yo2tm.ampr.org/nettools.php
and it's OK !
my ip is 44.153.32.97
---------
Hola !! como puedo testear el ping hacia mi ip ..
mi route en dmz activado dirigido a mi pc
yo probe la pagina http://yo2tm.ampr.org/nettools.php
y esta bien !
mi ip es 44.153.32.97
--
======================================================================
La vida nunca nos depara lo que queremos en el momento apropiado. Las
aventuras ocurren, pero no puntualmente.
-- Edward Morgan Foster.
======================================================================
__ __ __ __
| / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz
|__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300
== power by linux === NODO LU9DCE.DYNU.COM PORT 3694
## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ##
*** https://www.facebook.com/groups/newpacketradio/
Hello everyone
I have a running FBB baires
I would like to have a fwd with a colleague
europe or usa network by 44
if there is any colleague who could - I would appreciate
I leave my email lu9dce(a)gmail.com
regards
73
--
======================================================================
El joven conoce las reglas, el viejo las excepciones.
======================================================================
__ __ __ __
| / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz
|__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300
== power by linux === NODO LU9DCE.DYNU.COM PORT 3694
## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ##
*** https://www.facebook.com/groups/newpacketradio/
> Subject:
> [44net] test ampr bbs
> From:
> Eduardo Castillo <lu9dce(a)gmail.com>
> Date:
> 10/12/2016 06:46 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> pls test bbs 44.153.32.97 port 6300 !!
>
> send report !! my mail lu9dce(a)gmail.com !! tks !!
I can't connect it. There appears to be a tunnel route to 44.153.32.97 via 181.192.58.28 but I
can't even ping 44.153.32.97 so probably there is some issue, maybe the wellknown NAT DMZ issue?
Rob
> 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
