How can there be incoming connections when using a VPN?

Question

I've the following nftable configuration (/etc/nftables.conf) to enforce a "VPN kill switch". Except for ICMP and IGMP, connections are only allowed through tun0. This works well as a "kill switch".

#!/usr/sbin/nft -f

flush ruleset

table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state vmap { invalid : drop, established : accept, related : accept }
        ct state new limit rate over 3/minute log prefix "NFT_DROP_RATE: " drop
        meta l4proto icmp accept
        ip protocol igmp accept
        log prefix "NFT_DROP_IN: "
    }

    chain forward { type filter hook forward priority 0; policy drop; }

    chain openvpn {
        type filter hook output priority 0; policy drop;
        oifname { "lo", "tun0" } accept
        udp dport openvpn accept
        meta l4proto icmp accept
        ip protocol igmp accept

        # explicitly drop dns to exclude from logging before policy drop
        tcp dport domain drop
        udp dport domain drop
        log prefix "NFT_DROP_OUT: "
    }
}

However, there are log entries of new incoming connections via tun0 soon after I connect to the vpn (proton vpn) without ever initiating a connection. SRC IPs are not the vpn host's IP.

NFT_DROP_IN: IN=tun0 OUT= MAC= SRC=216.58.214.3 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59449 DF PROTO=TCP SPT=443 DPT=53297 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_IN: IN=tun0 OUT= MAC= SRC=40.113.103.199 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=45843 DF PROTO=TCP SPT=443 DPT=53299 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_IN: IN=tun0 OUT= MAC= SRC=13.107.21.237 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=16351 DF PROTO=TCP SPT=443 DPT=53302 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_IN: IN=tun0 OUT= MAC= SRC=13.107.246.67 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=21346 DF PROTO=TCP SPT=443 DPT=53301 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_IN: IN=tun0 OUT= MAC= SRC=142.250.102.188 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=35208 DF PROTO=TCP SPT=5228 DPT=53303 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=185.255.134.248 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=6862 DF PROTO=TCP SPT=3333 DPT=53300 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=162.159.133.234 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=54318 DF PROTO=TCP SPT=443 DPT=53308 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=44.217.29.101 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=32804 DF PROTO=TCP SPT=443 DPT=53310 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=216.58.214.3 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59450 DF PROTO=TCP SPT=443 DPT=53297 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=40.113.103.199 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=45844 DF PROTO=TCP SPT=443 DPT=53299 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=13.107.246.67 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=21347 DF PROTO=TCP SPT=443 DPT=53301 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=13.107.21.237 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=16352 DF PROTO=TCP SPT=443 DPT=53302 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=162.159.133.234 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=54319 DF PROTO=TCP SPT=443 DPT=53308 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_DROP_RATE: IN=tun0 OUT= MAC= SRC=44.217.29.101 DST=10.96.0.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=32805 DF PROTO=TCP SPT=443 DPT=53310 WINDOW=251 RES=0x00 ACK URGP=0

How does that work? I thought when a machine is behind a VPN, others cannot know of the VPN client. That only the VPN server is seen. How does one create a new connection and send an incoming packet via a VPN server?

If I do nft delete chain inet filter openvpn and switch to using regular internet, I don't get these incoming connections.

EDIT 1

I forgot to mention before that there is no pattern to when this happens. It can be as soon as I start the VPN or after a while.

I added lines iifname "tun0" log prefix "NFT_TUN: " and oifname "tun0" log prefix "NFT_TUN: " to the very top of my nftables input and openvpn chains and got the following at the very beginning of a particular session. I restarted my VPN several times to make sure that nothing went out while I wait for it.

NFT_TUN: IN= OUT=tun0 SRC=fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.98 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=38887 DF PROTO=TCP SPT=443 DPT=47114 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=15.197.255.117 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52458 DF PROTO=TCP SPT=443 DPT=51646 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=55680 DF PROTO=TCP SPT=80 DPT=32874 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.110 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=51353 DF PROTO=TCP SPT=443 DPT=44922 WINDOW=253 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=38095 DF PROTO=TCP SPT=80 DPT=32884 WINDOW=252 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=157.240.247.13 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52315 DF PROTO=TCP SPT=443 DPT=58498 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=49.0.204.157 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=29898 DF PROTO=TCP SPT=80 DPT=55644 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.250.102.188 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2334 DF PROTO=TCP SPT=5228 DPT=36822 WINDOW=252 RES=0x00 ACK URGP=0 
NFT_TUN: IN= OUT=tun0 SRC=fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=23.2.13.219 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=20253 DF PROTO=TCP SPT=80 DPT=56676 WINDOW=254 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=114.119.173.233 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=13796 DF PROTO=TCP SPT=80 DPT=55722 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=33966 DF PROTO=TCP SPT=80 DPT=32866 WINDOW=253 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.250.102.188 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2335 DF PROTO=TCP SPT=5228 DPT=36822 WINDOW=252 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=23.2.13.219 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=40989 DF PROTO=TCP SPT=80 DPT=56674 WINDOW=254 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=23.2.13.203 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=62292 DF PROTO=TCP SPT=80 DPT=56984 WINDOW=254 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=114.119.173.233 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=13797 DF PROTO=TCP SPT=80 DPT=55722 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=2.18.244.77 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=8057 DF PROTO=TCP SPT=443 DPT=34968 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60774 DF PROTO=TCP SPT=80 DPT=32860 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=55681 DF PROTO=TCP SPT=80 DPT=32874 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=94.74.95.153 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=31221 DF PROTO=TCP SPT=443 DPT=47254 WINDOW=253 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.36.2 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24711 DF PROTO=TCP SPT=443 DPT=50962 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=71.18.73.0 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=26201 DF PROTO=TCP SPT=443 DPT=37184 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=52.77.74.159 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=38096 DF PROTO=TCP SPT=80 DPT=32884 WINDOW=252 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=23.2.13.225 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=13449 DF PROTO=TCP SPT=80 DPT=33898 WINDOW=254 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.110 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19627 DF PROTO=TCP SPT=443 DPT=44920 WINDOW=253 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.98 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=38888 DF PROTO=TCP SPT=443 DPT=47114 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=15.197.255.117 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52459 DF PROTO=TCP SPT=443 DPT=51646 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.110 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=51354 DF PROTO=TCP SPT=443 DPT=44922 WINDOW=253 RES=0x00 ACK URGP=0 
NFT_TUN: IN= OUT=tun0 SRC=fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=49.0.204.157 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=29899 DF PROTO=TCP SPT=80 DPT=55644 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=157.240.247.13 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52316 DF PROTO=TCP SPT=443 DPT=58498 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=15.197.255.117 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52460 DF PROTO=TCP SPT=443 DPT=51646 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.110 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19628 DF PROTO=TCP SPT=443 DPT=44920 WINDOW=253 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=49.0.204.157 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=29900 DF PROTO=TCP SPT=80 DPT=55644 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.39.110 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=51355 DF PROTO=TCP SPT=443 DPT=44922 WINDOW=253 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=2.18.244.77 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=8058 DF PROTO=TCP SPT=443 DPT=34968 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=2.18.244.77 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=8059 DF PROTO=TCP SPT=443 DPT=34968 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=71.18.73.0 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=26202 DF PROTO=TCP SPT=443 DPT=37184 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=94.74.95.153 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=31222 DF PROTO=TCP SPT=443 DPT=47254 WINDOW=253 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=142.251.36.2 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24712 DF PROTO=TCP SPT=443 DPT=50962 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=157.240.247.13 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=52317 DF PROTO=TCP SPT=443 DPT=58498 WINDOW=251 RES=0x00 ACK RST URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=99.83.249.137 DST=10.96.0.6 LEN=180 TOS=0x00 PREC=0x00 TTL=64 ID=7561 DF PROTO=TCP SPT=443 DPT=44232 WINDOW=251 RES=0x00 ACK URGP=0 
NFT_TUN: IN=tun0 OUT= MAC= SRC=99.83.249.137 DST=10.96.0.6 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7562 DF PROTO=TCP SPT=443 DPT=44232 WINDOW=251 RES=0x00 ACK RST URGP=0

tcpdump matches

IP edge-star-shv-01-ams2.facebook.com.https > 10.96.0.6.58498: Flags [.], ack 2481075510, win 251, options [nop,nop,TS val 2585096131 ecr 2291077507], length 0
IP 49.0.204.157.http > 10.96.0.6.55644: Flags [.], ack 1990954482, win 251, options [nop,nop,TS val 4067941333 ecr 3098757724], length 0
IP rb-in-f188.1e100.net.5228 > 10.96.0.6.36822: Flags [.], ack 3435960491, win 252, options [nop,nop,TS val 3209627350 ecr 647372642], length 0
IP6 fe80::xxxx:xxxx:xxxx:xxxx > ip6-allrouters: ICMP6, router solicitation, length 8
IP a23-2-13-219.deploy.static.akamaitechnologies.com.http > 10.96.0.6.56676: Flags [R.], seq 363373683, ack 1347966157, win 254, options [nop,nop,TS val 963440120 ecr 1090252232], length 0
IP 114.119.173.233.http > 10.96.0.6.55722: Flags [.], ack 1738451071, win 251, options [nop,nop,TS val 1388336134 ecr 492495318], length 0
IP ec2-52-77-74-159.ap-southeast-1.compute.amazonaws.com.http > 10.96.0.6.32866: Flags [R.], seq 53591465, ack 3633789705, win 253, options [nop,nop,TS val 639714000 ecr 2139320507], length 0
IP rb-in-f188.1e100.net.5228 > 10.96.0.6.36822: Flags [R.], seq 1, ack 1, win 252, options [nop,nop,TS val 3209629394 ecr 647372642], length 0
IP a23-2-13-219.deploy.static.akamaitechnologies.com.http > 10.96.0.6.56674: Flags [R.], seq 2036504992, ack 470731109, win 254, options [nop,nop,TS val 963440120 ecr 1090243079], length 0
IP a23-2-13-203.deploy.static.akamaitechnologies.com.http > 10.96.0.6.56984: Flags [R.], seq 57571030, ack 3811642084, win 254, options [nop,nop,TS val 3082407453 ecr 3287754957], length 0
IP 114.119.173.233.http > 10.96.0.6.55722: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 1388336313 ecr 492495318], length 0
IP a2-18-244-77.deploy.static.akamaitechnologies.com.https > 10.96.0.6.34968: Flags [.], ack 1369544468, win 251, options [nop,nop,TS val 1994050879 ecr 4261075034], length 0
IP ec2-52-77-74-159.ap-southeast-1.compute.amazonaws.com.http > 10.96.0.6.32860: Flags [R.], seq 3654002292, ack 4107140307, win 251, options [nop,nop,TS val 639716559 ecr 2139321808], length 0
IP ec2-52-77-74-159.ap-southeast-1.compute.amazonaws.com.http > 10.96.0.6.32874: Flags [R.], seq 2918298001, ack 3516697958, win 251, options [nop,nop,TS val 639717583 ecr 2139323813], length 0
IP 94.74.95.153.https > 10.96.0.6.47254: Flags [.], ack 1433740019, win 253, options [nop,nop,TS val 1397022875 ecr 853766209], length 0
IP ams15s44-in-f2.1e100.net.https > 10.96.0.6.50962: Flags [.], ack 2936332628, win 251, options [nop,nop,TS val 3944327117 ecr 3299994497], length 0
IP 71.18.73.0.https > 10.96.0.6.37184: Flags [.], ack 417969557, win 251, options [nop,nop,TS val 173935806 ecr 1676174754], length 0
IP ec2-52-77-74-159.ap-southeast-1.compute.amazonaws.com.http > 10.96.0.6.32884: Flags [R.], seq 3011973634, ack 898249821, win 252, options [nop,nop,TS val 639718096 ecr 2139324595], length 0
IP a23-2-13-225.deploy.static.akamaitechnologies.com.http > 10.96.0.6.33898: Flags [R.], seq 1498891662, ack 2654159543, win 254, options [nop,nop,TS val 4156734098 ecr 3786473916], length 0
IP ams15s48-in-f14.1e100.net.https > 10.96.0.6.44920: Flags [.], ack 2649033937, win 253, options [nop,nop,TS val 1002398363 ecr 2576018370], length 0
IP ams15s48-in-f2.1e100.net.https > 10.96.0.6.47114: Flags [R.], seq 1995774347, ack 3187828247, win 251, options [nop,nop,TS val 3953577958 ecr 2119417552], length 0
IP a25e2c9c64530db8a.awsglobalaccelerator.com.https > 10.96.0.6.51646: Flags [.], ack 2080231293, win 251, options [nop,nop,TS val 2573130003 ecr 724848747], length 0
IP ams15s48-in-f14.1e100.net.https > 10.96.0.6.44922: Flags [.], ack 3287668770, win 253, options [nop,nop,TS val 1002400407 ecr 2576020467], length 0
IP6 fe80::xxxx:xxxx:xxxx:xxxx > ip6-allrouters: ICMP6, router solicitation, length 8
IP 49.0.204.157.http > 10.96.0.6.55644: Flags [.], ack 1, win 251, options [nop,nop,TS val 4067951569 ecr 3098757724], length 0
IP edge-star-shv-01-ams2.facebook.com.https > 10.96.0.6.58498: Flags [.], ack 1, win 251, options [nop,nop,TS val 2585106375 ecr 2291077507], length 0
IP a25e2c9c64530db8a.awsglobalaccelerator.com.https > 10.96.0.6.51646: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 2573132566 ecr 724848747], length 0
IP ams15s48-in-f14.1e100.net.https > 10.96.0.6.44920: Flags [R.], seq 1, ack 1, win 253, options [nop,nop,TS val 1002402711 ecr 2576018370], length 0
IP 49.0.204.157.http > 10.96.0.6.55644: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 4067953617 ecr 3098757724], length 0
IP ams15s48-in-f14.1e100.net.https > 10.96.0.6.44922: Flags [R.], seq 1, ack 1, win 253, options [nop,nop,TS val 1002403481 ecr 2576020467], length 0
IP a2-18-244-77.deploy.static.akamaitechnologies.com.https > 10.96.0.6.34968: Flags [.], ack 1, win 251, options [nop,nop,TS val 1994061123 ecr 4261075034], length 0
IP a2-18-244-77.deploy.static.akamaitechnologies.com.https > 10.96.0.6.34968: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 1994061123 ecr 4261075034], length 0
IP 71.18.73.0.https > 10.96.0.6.37184: Flags [.], ack 1, win 251, options [nop,nop,TS val 173946046 ecr 1676174754], length 0
IP 94.74.95.153.https > 10.96.0.6.47254: Flags [.], ack 1, win 253, options [nop,nop,TS val 1397033119 ecr 853766209], length 0
IP ams15s44-in-f2.1e100.net.https > 10.96.0.6.50962: Flags [.], ack 1, win 251, options [nop,nop,TS val 3944337361 ecr 3299994497], length 0
IP edge-star-shv-01-ams2.facebook.com.https > 10.96.0.6.58498: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 2585112520 ecr 2291077507], length 0
IP a7d88891d765cddfa.awsglobalaccelerator.com.https > 10.96.0.6.44232: Flags [.], seq 3751423686:3751423814, ack 2589544445, win 251, options [nop,nop,TS val 2204302807 ecr 3155826084], length 128
IP a7d88891d765cddfa.awsglobalaccelerator.com.https > 10.96.0.6.44232: Flags [R.], seq 5772, ack 1, win 251, options [nop,nop,TS val 2204304855 ecr 3155826084], length 0
IP 94.74.95.153.https > 10.96.0.6.47254: Flags [R.], seq 1, ack 1, win 253, options [nop,nop,TS val 1397043355 ecr 853766209], length 0
IP 71.18.73.0.https > 10.96.0.6.37184: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 173956286 ecr 1676174754], length 0
IP ams15s44-in-f2.1e100.net.https > 10.96.0.6.50962: Flags [R.], seq 1, ack 1, win 251, options [nop,nop,TS val 3944347601 ecr 3299994497], length 0
IP ams15s48-in-f10.1e100.net.https > 10.96.0.6.57804: Flags [.], seq 2112035405:2112035469, ack 270384259, win 253, options [nop,nop,TS val 655153027 ecr 820247796], length 64
IP ams15s48-in-f10.1e100.net.https > 10.96.0.6.57804: Flags [R.], seq 73, ack 1, win 253, options [nop,nop,TS val 655153028 ecr 820247796], length 0
IP 185.151.204.12.https > 10.96.0.6.40644: Flags [R.], seq 1977279825, ack 3776024183, win 253, options [nop,nop,TS val 3887926337 ecr 136394206], length 0
IP ams15s44-in-f2.1e100.net.https > 10.96.0.6.50946: Flags [R.], seq 3919008919, ack 334954759, win 251, options [nop,nop,TS val 3944347602 ecr 3299994803], length 0

I doubt that the traffic originated from my side. And I don't think it is due to connection resets since my 10.96.0.0/16 address changes on reset.

this is typical for vpn service providers to allow incoming connections under certain circumstances (eg. client-configured port forwarding) .. logically speaking, you're joining a Network, and the service provider could have configured incoming connections (for whatever reason) - you need to configure your host to limit the scope (as you've done) - when you were using regular inet the isp was probably blocking all incomings — brynk, Commented Jul 22 at 12:25
@brynk I sort of understand what you are saying. About port forwarding though, that should only be for clients that set up port forwarding right? I wouldn't get traffic in a port because another client has set up port forwarding. Right? I'm quite new to networking and is trying to learn more. It would make sense that the traffic originated from my vpn provider. But, SRCs does not agree with that. Proton vpn provides ip.me which usually tells you when an address belongs to them. Furthermore, it's weird that they would use SPT 3333 or 5228 to send TCP ACK. — Navi, Commented Jul 22 at 13:14
yes i agree it should be only if clients configure it - having said that, i too have period "back connections" blocked from http server ports on external ip addies, eg. your first ip is google: mxtoolbox.com/… ; also, this q suggests it could be a blocked response after the connection was initiated by your host. either way, it would be possible for any server to reconnect back to your vpn exit-node ip and port, with packets possibly being routed back to your host (typical p2p behaviour) — brynk, Commented Jul 22 at 14:13

stitchmeup · Accepted Answer · 2024-07-25 11:21:55Z

TCP is a stateful protocol. Any segments with the ACK flag must match a prior segement sent by the host. Any communication in TCP is initiated through a handshake first.

Netfilter conntrack state new matches packets that are not yet tracked. Since TCP is a stateful protocol, it is not expected behavior to see TCP segment with the ACK flag to log as a packet matching the conntrack state new. Usually, for TCP, in the input chain, this state would be matched by a TCP segment with a SYN flag.

A consumer grade VPN like Proton VPN acts as a proxy for output traffic. It does so by building a tunnel between the remote host (client) and its infrastructure through a server acting as a gateway (in this case, it uses OpenVPN). All the traffic from the client (or only a selected part of it) is then sent out through the tunnel once it is set up. There is no need for the VPN provider to initiate any kind of unicast connection to client for whatever reason through the tunnel.

The destination port of the logged segment likely rules out a port forwarding configuration allowing host on the internet to reach the host behind the proxy by hitting a particular port on the VPN provider's gateway. And there is no way a VPN provider would allow random hosts on the internet to initiate a connection to the client on purpose. This would be a security issue (as the client is part of a private network inside the VPN provider infrastructure), and it is very unlikely it does IPv4 Source NAT automatically for all the VPN clients.

Because of all of this, this is indeed some odd traffic logged. I would confirm first that the host did not initiate any connection. One way to be confirm it is unsolicited traffic is to capture all traffic on the TUN/TAP interface created by the VPN with tcpdump or Wireshark. If you don't capture the related TCP segments (with the SYN flag), then it is a bug or a security flaw in the VPN network implementation. In this case, only the VPN provider could give insights about the issue and explain how those segments reach the client.

EDIT: I corrected my first answer to add more description why the traffic logged is unusual if the host did not initiate a TCP communication.

If the client closes the connection but doesn't inform the server, wouldn't this be the result where conntrack state is reset to NEW even though the server is still talking? — multithr3at3d, Commented Jul 24 at 1:34
@multithr3at3d Every new session gets me a new 10.96.0.0/16 address. Can "pending" traffic from a previous session reach me once my address changes? — Navi, Commented Jul 24 at 5:38
@multithr3at3d, well, it could be but TCP is a stateful protocol, and this is true for closing the connection too. In TCP, you do not close a connection abruptly everytime. Most of the time, it is done properly and their is mechanisms to close the connection. A TCP connection goes through different states that can be checked using the command ss -t. @Navi, how long between your previous connection and the new one? Their is expiration delay. — stitchmeup, Commented Jul 24 at 8:15
For the new logs I posted, I was restarting connections say every minute. So I start VPN, wait for a minute to see if something comes in, and turned it off and on again. But my computer sent nothing out via tun0 in any of the sessions. I just get a new 10.96.0.0/24 address. Also, I turned my computer back on now after more than 2 hours and the first connection got similar incoming. — Navi, Commented Jul 24 at 10:45
I sent a support request yesterday to ProtonVPN and today they responded that it has been forwarded to a team. I'll wait to hear from them. — Navi, Commented Jul 24 at 10:47

multithr3at3d · Accepted Answer · 2024-07-24 01:23:16Z

1

Are you sure nothing on your system is open and making outbound connections? You may want to confirm that with e.g. tcpdump. Many of the logged packets have TCP source port 443, indicating they likely come from a web server. It is possible that something initiated an outbound connection, and the server is still trying to reply to you even though something on your end has since closed the connection. In this case, the VPN provider is allowing these packets to reach you since they relate to an established (or recently established) connection.

answered Jul 24 at 1:23

multithr3at3d

13.1k3 gold badges32 silver badges44 bronze badges

That's what I believe now. See new logs in the post.
– Navi
Commented Jul 24 at 5:41

Add a comment |

Stack Exchange Network

How can there be incoming connections when using a VPN?

EDIT 1

2 Answers 2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged
linux
vpn
openvpn
iptables
.

Linked

Hot Network Questions

How can there be incoming connections when using a VPN?

EDIT 1

2 Answers 2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged linuxvpnopenvpniptables.

Linked

Related

Hot Network Questions

Not the answer you're looking for? Browse other questions tagged
linux
vpn
openvpn
iptables
.