Re: Varying source address and stateful firewalls (Was: Multiple Endpoints)

Re: Varying source address and stateful firewalls (Was: Multiple Endpoints)

[em12345]

Hi Baptiste,

after seeing

    https://wiki.asterisk.org/wiki/display/TOP/NAT+Traversal+Testing

I realized that the connection tracking with its state calculation and
the SNAT port mapping are two different things which don't have to
follow the same rules related to src/dst IP and ports.

This could be an explanation why Jason tested the NATed whole punching
successful with different src IPs, while your example failed.

The iptables connection tracking really does include src and dst IP
according to:

     http://www.iptables.info/en/connection-state.html

So iptables ESTABLISHED filter rules require the src,dst and both ports.

But may be the iptables NAT port mapping does not require this. The
iptables man page is vague on MASQUERADE and SNAT target.


Anyway, only packets with an existing port mapping (however this is
determined) will make it into the FORWARD chain from WAN to LAN interface.
Therefore it would not really be necessary to check for ESTABLISHED in
the FORWARD chain for those WAN-to-LAN packets. Assuming that there are
really showing up such NEW packets.

However in your example which is only using the INPUT chain, one of
course has to filter out the NEW packets here.


Emmanuel

Re: Varying source address and stateful firewalls (Was: Multiple Endpoints)

[Jason A. Donenfeld]

Hey,

Thanks for the nice analysis. At first I was incredulous about the
results, but then I sat down and drew some pictures, and figured out
where the disconnect is. With hole punching, you have each peer
discovering the remote endpoint tuple, and sending an outgoing packet,
which then adjusts the stateful firewall. With em's example, there
isn't this luxury. So, I'll circle back the original thread, and
backtrack on my assertions in order to get back on track. Thanks for
investigating and showing where I erred.

Jason

Varying source address and stateful firewalls (Was: Multiple Endpoints)

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On Mon, Jan 09, 2017 at 12:00:17AM +0100, Jason A. Donenfeld wrote:
> > I merely pointed out that a stateful firewall is similar to a symmetric
> > NAT, that is, both would cause issue with peer roaming.
> 
> Are you sure about this for UDP? I did a bunch of tests several months
> ago, and was able to punch holes in a variety of stateful firewalls
> with changing remote IPs.

I must admit I had never tested :)

I just did, though, and yes, the stateful firewall from Linux does block
UDP traffic from unrelated source IP addresses.  So I guess your hole
punching was based on some other property.

Here is the setup with 3 computers A, B, C.  There is a stateful firewall
on A, and A opens a UDP connection towards B.  C then tries to pretend to
be B and contacts A with the same src/dest port.

    A# iptables -F INPUT
    A# iptables -A INPUT -p udp -m conntrack --ctstate ESTABLISHED -j LOG --log-prefix="established: "
    A# iptables -A INPUT -p udp -m conntrack --ctstate RELATED -j LOG --log-prefix="related: "
    A# iptables -A INPUT -p udp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    A# iptables -A INPUT -p udp -j LOG --log-prefix="drop: "
    A# iptables -A INPUT -p udp -j DROP

A and B communicate normally:

    B# nc -l -u -p 5001
    A# nc -u -p 60000 $IP_B 5001
    A# #type something
    B# #type something else

At this point, there is an entry in the conntrack table of A:

    A# conntrack -L | grep $IP_B
    udp      17 22 src=$IP_A dst=$IP_B sport=60000 dport=5001 src=$IP_B dst=$IP_A sport=5001 dport=60000 mark=0 use=1

Also, the packet from B to A has been logged by our firewall rules:

    kernel: established: IN=wlan0 OUT= SRC=$IP_B DST=$IP_A LEN=33 TOS=0x00 PREC=0x00 TTL=62 ID=43432 DF PROTO=UDP SPT=5001 DPT=60000 LEN=13

Now C tries to chime in, contacting A and pretending to be B:

    C# nc -u -p 5001 $IP_A 60000

The result:

    kernel: drop: IN=wlan0 OUT= SRC=$IP_C DST=$IP_A LEN=34 TOS=0x00 PREC=0x00 TTL=64 ID=43124 DF PROTO=UDP SPT=5001 DPT=60000 LEN=14

So, the packet from C is dropped, even though it has the same source port
and destination port as the ones from B.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]