AWS Security Group show 'UDP Port open' while it should deny?

Question

Security group 'show that UDP port is open' while it should deny connection.

I have an instance vpn2-a

vpn2-a i-xxxxxxxxx 11.11.11.11

I'd like to limit the access to UDP port 1194 of that instance, to accept connection from following private IP address:

    55.55.55.55/32, 66.66.66.66/32

I've created SG and attached to instance vpn2-a

vpn_1_2-vpn12-security-group
1194    udp 55.55.55.55/32, 66.66.66.66/32

---

1. Test if it is working:

I do perform some 'port open' test from the allowed vpn1-a 55.55.55.55

vpn1-a$ $ nc -vv 11.11.11.11 1194 -u
Connection to 11.11.11.11 1194 port [udp/openvpn] succeeded!

great, now let's see, is the port blocked from random IP:

RANDOM_HOST$ nc -vv 11.11.11.11 1194 -u
Connection to 11.11.11.11 1194 port [udp/openvpn] succeeded!

^^ how???? It suppose to be deny !!! Please Explain that

---

2. Debbuging:

It made me realy confused, but I did perform some tests:

At the vpn2-a instance:

vpn2-a#  /etc/init.d/openvpn stop

As You can see - nothing is listening on port 1194

vpn2-a## netstat -unpa
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:747             0.0.0.0:*                           7356/rpcbind
udp        0      0 0.0.0.0:31885           0.0.0.0:*                           587/dhclient
udp        0      0 0.0.0.0:68              0.0.0.0:*                           587/dhclient
udp        0      0 0.0.0.0:111             0.0.0.0:*                           7356/rpcbind
udp        0      0 10.118.0.152:123        0.0.0.0:*                           5434/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           5434/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           5434/ntpd
udp6       0      0 :::747                  :::*                                7356/rpcbind
udp6       0      0 :::1082                 :::*                                587/dhclient
udp6       0      0 :::111                  :::*                                7356/rpcbind
udp6       0      0 fe80::41:123        :::*                                5434/ntpd
udp6       0      0 ::1:123                 :::*                                5434/ntpd
udp6       0      0 :::123                  :::*                                5434/ntpd

No now, the testing from Random IP

RANDOM_HOST$ nc -vv 11.11.11.11 1194 -u
Connection to 11.11.11.11 1194 port [udp/openvpn] succeeded!

and from vpn1-a 55.55.55.55

vpn1-a$ $ nc -vv 11.11.11.11 1194 -u
[nothing]

---

So - I can only guess, that the 1194 connection is somehow open at AWS "Firewall proxy", that first open the port, and then check security group? Please provide the explanation or a way to fix the SG so that it says 'Port Closed', when it is defined at the security group.

Answer 1

The reason is very simple: UDP is connectionless. There are no acknowledgements, so "success" and a packet that has entered a black hole are indistinguishable.

If you send a UDP packet to destination, and it isn't actively refused or unroutable, it will appear to succeed.

This is potentially an illusion. UDP has no mechanism to indicate actual success, so the succeeded! message is simply telling you that no active failure was detected.

The security groups in AWS do not actively refuse unauthorized traffic -- they silently discard it. If I try to send a ping (ICMP echo request) or make a TCP connection to your instance, I would get "request timed out" or "connection timed out" if I were not allowed by your security group. But with UDP, the sender has no way to detect whether the packets are forwarded or discarded.

In short, what you are seeing is normal behavior, and does not mean the traffic is actually being allowed through. You should be able to confirm this with a packet sniffer on the machine you're trying to access... the traffic is blocked then you won't see it, unless you allow it via the security group.

Note, however, that security groups are stateful. You do not actually have to provision an incoming UDP mapping to run openvpn through on a fixed point to point configuration, if outbound traffic is already allowed, because when server A sends a UDP packet to port 1194 on a destination server B, the network infrastructure will "remember" this for a few minutes (until there is no traffic), and if server B responds back to server A using the same UDP port on which it was contacted, the network allows this through, on the assumption that A would not send traffic to B unless replies were supposed to be authorized... a DNS query response is a common example of such behavior... so if point-to-point openvpn over UDP works even without inbound security group rules allowing it, this is also expected behavior and does not mean the security group isn't doing it's job.