#StackBounty: #networking #server #vpn #iptables #openvpn OPENVPN: MULTI: bad source address from client

Bounty: 50

I struggled this problem for two days, but the problem is still here. Hope someone can provide suggestion or the way how to diagnose it.

What i want is let all client visit Internet over the OpenVPN server. Therefore, I first follow instructions Routing all client traffic (including web-traffic) through the VPN. After configuration, and setup iptables, the connection between VPN server and client succeeds, but the client can not visit any website (the brower is hang there). The ping from server and client are OK.

I checked log at the server, and there are some records like:

   Oct  3 09:16:21 iZbp15fejv9adv7o3izfm1Z ovpn-delta[1827]: laptop/131.202.XX.XX:59701 UDPv4 READ [93] from [AF_INET]131.202.XX.XX:59701: P_DATA_V1 kid=0 DATA len=92
    Oct  3 09:16:21 iZbp15fejv9adv7o3izfm1Z ovpn-delta[1827]: laptop/131.202.XX.XX:59701 MULTI: bad source address from client [131.202.XX.XX], packet dropped

where the IP: 131.202.XX.XX is my laptop IP address. This record is explained in “MULTI: bad source address from client , packet dropped” or “GET INST BY VIRT: [failed]”, why this IP is not 10.8.0.6 (tun0) at my laptop, and the detail implementation for the problem? My laptop connects to Internet using WIFI, and it is a device that runs openvpn --config client.conf.

As this is very simple example, Do I have a way to avoid this error, or any sample to config client-config-dir and create a ccd file

the /etc/openvpn/delta.conf at the server:

# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d

port 1194

proto udp

dev tun

;dev-node MyTap

ca ca.crt
cert delta.crt
key delta.key  # This file should be kept secret

dh dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

;server-bridge

;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script

;push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"

;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"

keepalive 10 120

;tls-auth ta.key 0 # This file is secret

;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
comp-lzo
;max-clients 100
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log         openvpn.log
;log-append  openvpn.log
verb 3
;mute 20

while the client.conf is:

   client
dev tun
proto udp
remote 116.62.193.49 1194
;remote my-server-2 1194
;remote-random

resolv-retry infinite

nobind

persist-key
persist-tun
ca ca.crt
cert laptop.crt
key laptop.key
ns-cert-type server

;tls-auth ta.key 1
comp-lzo

verb 3
;mute 20

For IP router configuration, I added the iptables to /etc/rc.local, so that iptables can be changed at server startup.

root@iZbp15fejv9adv7o3izfm1Z:/var/log# cat /etc/rc.local 
#!/bin/sh -e
#
# rc.local
#I also tried comment out first three instructions, but still does not work 
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

service dnsmasq restart

exit 0

and the /etc/sysctl.conf

net.ipv4.ip_forward=1

telnet serverIP 80 is OK. In the server: /var/logs/syslog:

Is there any solution?


Get this bounty!!!

#StackBounty: #iptables #openvpn #route #iproute2 #dante Two instances of Dante proxy server with two interfaces

Bounty: 50

I’m running 2 instances of Dante server on my Linux machine, one of them is called danted which is supposed to connect me to the internet through the ethernet cable and the other is sockd which is supposed to connect me through an OpenVPN connection..

The first one, danted is configured to use my ethernet cable (ens33):

internal: ens33 port=1080
external: ens33

The second one, sockd is configured to use the OpenVPN interface (tun0):

internal: ens33 port=2080
external: tun0

The Dante servers are configured properly and when OpenVPN is not connected, danted works fine but when OpenVPN connects, danted doesn’t work anymore. When I check it’s logs, I just see that the connection times out.

My routing table when OpenVPN is not connected looks like this:

default via 192.168.1.1 dev ens33 src 192.168.1.10 metric 202 
default via 192.168.1.1 dev ens33 proto dhcp metric 20001 
169.254.0.0/16 dev ens33 scope link metric 1000 
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.10 metric 1 
192.168.1.0/24 dev ens33 proto dhcp scope link src 192.168.1.10 metric 202 

And when OpenVPN connects, it looks like this:

0.0.0.0/1 via 10.123.58.1 dev tun0 
default via 192.168.1.1 dev ens33 src 192.168.1.10 metric 202 
default via 192.168.1.1 dev ens33 proto dhcp metric 20001 
10.123.58.0/23 dev tun0 proto kernel scope link src 10.123.58.65 
128.0.0.0/1 via 10.123.58.1 dev tun0 
169.254.0.0/16 dev ens33 scope link metric 1000 
openvpn.server.wan.ipaddress via 192.168.1.1 dev ens33 
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.10 metric 1 
192.168.1.0/24 dev ens33 proto dhcp scope link src 192.168.1.10 metric 202

So OpenVPN adds 4 new routes to my table. I’ve tried individually deleting each of these rules or also did ip route flush dev tun0 or deleted the 0/1 rule and added a default rule for the tun0 interface; but when I try these, and test the sockd proxy server, my IP is my ethernet cable’s IP, not OpenVPN’s server IP.

I have no idea how to fix this, I’ve been Googling this a lot, I thought this was an easy task since Dante proxy server just binds to external connections.

Summary for the bounty:

I’ve tried using my interface’s IPv4 addresses instead of the interface names, for example I used 192.168.1.10 instead of ens33 and used 10.123.58.1 instead of tun0, but didn’t fix the issue (I know that OpenVPN’s internal address changes every time we reconnect).

I am specifying the external (outgoing) interface in Dante configs, so from my understanding, it really shouldn’t be using the Ubuntu’s routing table, doesn’t it just listen to incoming connections and forward them to the external interface? I don’t understand why the OpenVPN added routes causes me issues, even thought I can easily ping computers on my local network, I’ve checked there are no firewall rules added to my iptables (iptables -n -v -L).

Here are the logs when I test the SOCKS server:

[18:18] Testing Started.
    Proxy Server
    Address:    192.168.1.10:1080
    Protocol:   SOCKS 5
    Authentication: NO

[18:18] Starting: Test 1: Connection to the Proxy Server
[18:18] IP Address: 192.168.1.10
[18:18] Connection established
[18:18] Test passed.
[18:18] Starting: Test 2: Connection through the Proxy Server
[18:18] Authentication was successful.
[18:49] Error : the proxy server cannot establish connection to www.google.com:80
    Error = 0x06 (Timeout).
    Please confirm that the target host address is correct.
    The error may also indicate that the proxy server is not operating properly.
[18:49] Test failed.
[18:49] Testing Finished.

The target host address is correct, I’ve checked dante-server’s logs as I’ve said above, and I can see google.com’s IP address:

Aug 26 19:01:11 (1629988271.706256) danted[106897]: info: pass(2): tcp/connect ]: 0 -> 192.168.1.15.9786 192.168.1.10.1080 -> 0, 0 -> 192.168.1.10.9786 142.250.186.174.443 -> 0: connect timeout.  Session duration: 31s

When OpenVPN is disconnected, a successful connection looks like this:

Aug 26 19:06:18 (1629988578.802869) danted[106897]: info: pass(2): tcp/connect ]: 0 -> 192.168.1.15.9796 192.168.1.10.1080 -> 0, 0 -> 192.168.1.129.9796 142.250.185.238.443 -> 0: local client closed.  Session duration: 10s

My question is specific about Dante-SOCKS5-Server, although I have tried Squid-HTTPS-Server and I had the same issue with it:

My question is specific about Dante-SOCKS5-Server, although I have tried Squid-HTTPS-Server and I had the same issue with it:
[05:40] Starting: Test 1: Connection to the Proxy Server
[05:40] IP Address: 192.168.1.10
[05:40] Connection established
[05:40] Test passed.
[05:40] Starting: Test 2: Connection through the Proxy Server
[06:40] Error : the proxy server cannot establish connection with 142.250.186.174:443
    The error indicates that the target host is down or unreachable.
    Please try to use another host and/or port as a test target.
    The proxy server reply header is:
        HTTP/1.1 503 Service Unavailable
        Server: squid/4.10
        Mime-Version: 1.0
        Date: Thu, 26 Aug 2021 16:36:40 GMT
        Content-Type: text/html;charset=utf-8
        Content-Length: 3438
        X-Squid-Error: ERR_CONNECT_FAIL 110
        Vary: Accept-Language
        Content-Language: en
[06:40] Test failed.
[06:40] Testing Finished.


Get this bounty!!!

#StackBounty: #linux #networking #security #iptables #linux-networking Is there a way to obtain CPS and Thruoghput metrics in Linux?

Bounty: 100

I want to analyze my Debian 9 server’s network workload to detect some possible network overloads.

The main metrics I need to analyze are:

  • CPS (connections per second)
  • Throughput

Is there a way to obtain these metrics from within Linux?
I thought that CPS metric could be somehow obtained through conntrack NEW connections events but not sure that this would be the most proper way..

Sorry if obvious.

P.S. this server handles not only local traffic, it also forward a lot of traffic.


Get this bounty!!!

#StackBounty: #iptables #port-forwarding #ipsec #strongswan #port-mirroring Mirror incoming traffic on specific port to another IP, usi…

Bounty: 50

I want to internally publish an SMTP server (IP 10.0.0.10) that is behind a VPN tunnel on my internal server (192.168.0.10) using strongswan. My strongswan is running within a docker container.

For this I want my internal server 192.168.0.10 to listen to its 25 port and to forward the traffic to the tunneled server on the same port 10.0.0.10:25.

So far I tried using iptables, but without success.

my iptables-save on 192.168.0.10 after strongswan is connected to the tunnel: (and yes I can ping the 10.0.0.10 from 192.168.0.10)

# Generated by iptables-save v1.8.4 on Fri Jul 23 09:55:05 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 10.0.0.0/16 -d 192.168.0.10/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 192.168.0.10/32 -d 10.0.0.0/16 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Fri Jul 23 09:55:05 2021
# Generated by iptables-save v1.8.4 on Fri Jul 23 09:55:05 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [2:1600]
:POSTROUTING ACCEPT [2:1600]
:DOCKER_OUTPUT - [0:0]
:DOCKER_POSTROUTING - [0:0]
-A OUTPUT -d 127.0.0.11/32 -j DOCKER_OUTPUT
-A POSTROUTING -d 127.0.0.11/32 -j DOCKER_POSTROUTING
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.11:45165
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.11:53306
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p tcp -m tcp --sport 45165 -j SNAT --to-source :53
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p udp -m udp --sport 53306 -j SNAT --to-source :53
COMMIT

I tried various commands like these:

iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 10.0.0.10:25
iptables -t nat -A POSTROUTING -p tcp -d 10.0.0.10 --dport 25 -j SNAT --to-source 192.168.0.10

but without success.

What am I doing wrong?


Get this bounty!!!

#StackBounty: #linux #networking #iptables #linux-networking Is there a way to obtain CPS and Thruoghput metrics in Linux?

Bounty: 100

I want to analyze my Debian 9 server’s network workload to detect some possible network overloads.

The main metrics I need to analyze are:

  • CPS (connections per second)
  • Throughput

Is there a way to obtain these metrics from within Linux?
I thought that CPS metric could be somehow obtained through conntrack NEW connections events but not sure that this would be the most proper way..

Sorry if obvious.

P.S. this server handles not only local traffic, it also forward a lot of traffic.


Get this bounty!!!

#StackBounty: #networking #server #iptables #firewall Can't connect to open secure port on Ubuntu

Bounty: 50

I opened the 8443 port on which I run Clickhouse server. I can connect to SSH on 22 port, I can also connect to 8443 via SSH tunnel, however I can’t connect normally to that host. I’m trying to connect from the Windows machine, if that is related anyhow. I even opened outbound port (pretty sure that it is redundant).

I tried to disable firewall and then I was able to connect. What can be wrong?

user@myhost:~/d/clickhouse$ sudo ufw status
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
9440/tcp                   ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
8443                       ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
9440/tcp (v6)              ALLOW       Anywhere (v6)             
8443 (v6)                  ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)

user@myhost:~/d/clickhouse$ sudo lsof -iTCP -sTCP:LISTEN -P
COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd-r    841 systemd-resolve   13u  IPv4   26021      0t0  TCP localhost:53 (LISTEN)
vsftpd       901            root    3u  IPv6   26299      0t0  TCP *:21 (LISTEN)
sshd        1037            root    3u  IPv4   29181      0t0  TCP *:22 (LISTEN)
sshd        1037            root    4u  IPv6   29183      0t0  TCP *:22 (LISTEN)
docker-pr  86081            root    4u  IPv6  520074      0t0  TCP *:8088 (LISTEN)
docker-pr 287023            root    4u  IPv6 1831110      0t0  TCP *:8086 (LISTEN)
docker-pr 318522            root    4u  IPv6 2109586      0t0  TCP *:9440 (LISTEN)
docker-pr 318537            root    4u  IPv6 2110806      0t0  TCP *:8443 (LISTEN)
node      354955           user   18u  IPv4 2274703      0t0  TCP localhost:34575 (LISTEN)

user@myhost:~/d/clickhouse$ netstat -an | grep "LISTEN "
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:34575         0.0.0.0:*               LISTEN     
tcp6       0      0 :::21                   :::*                    LISTEN     
tcp6       0      0 :::8086                 :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::8088                 :::*                    LISTEN     
tcp6       0      0 :::8443                 :::*                    LISTEN     
tcp6       0      0 :::9440                 :::*                    LISTEN 

UPDATE:

on the server I ran sudo tcpdump -ni eth0 port 8443 and then on client machine I ran nc -zv 192.168.1.58 8443:

user@myhost:~$ sudo tcpdump -ni eth0 port 8443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:05:51.368952 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434934937 ecr 0,nop,wscale 7], length 0
15:05:52.380268 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434935948 ecr 0,nop,wscale 7], length 0
15:05:54.460280 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434938028 ecr 0,nop,wscale 7], length 0
15:05:58.540705 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434942109 ecr 0,nop,wscale 7], length 0
15:06:06.940802 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434950509 ecr 0,nop,wscale 7], length 0
15:06:23.581056 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434967149 ecr 0,nop,wscale 7], length 0
15:06:56.221198 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434999788 ecr 0,nop,wscale 7], length 0

and nc failed with the message nc: connect to 192.168.1.58 port 8443 (tcp) failed: Connection timed out

The output of sudo ufw status verbose

user@myhost:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
9440/tcp                   ALLOW IN    Anywhere                  
8443/tcp                   ALLOW IN    Anywhere                  
8443                       ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
9440/tcp (v6)              ALLOW IN    Anywhere (v6)             
8443 (v6)                  ALLOW IN    Anywhere (v6)             
8443/tcp (v6)              ALLOW IN    Anywhere (v6)  

I can connect to service if firewall is disabled:

nc -zv 192.168.1.58 8443 
Connection to 192.168.1.58 8443 port [tcp/*] succeeded!

I can connect to service with IPv4 address if firewall is disabled:
enter image description here


Get this bounty!!!

#StackBounty: #networking #server #iptables #firewall Can't connect to open secure port on Ubuntu

Bounty: 50

I opened the 8443 port on which I run Clickhouse server. I can connect to SSH on 22 port, I can also connect to 8443 via SSH tunnel, however I can’t connect normally to that host. I’m trying to connect from the Windows machine, if that is related anyhow. I even opened outbound port (pretty sure that it is redundant).

I tried to disable firewall and then I was able to connect. What can be wrong?

user@myhost:~/d/clickhouse$ sudo ufw status
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
9440/tcp                   ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
8443                       ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
9440/tcp (v6)              ALLOW       Anywhere (v6)             
8443 (v6)                  ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)

user@myhost:~/d/clickhouse$ sudo lsof -iTCP -sTCP:LISTEN -P
COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd-r    841 systemd-resolve   13u  IPv4   26021      0t0  TCP localhost:53 (LISTEN)
vsftpd       901            root    3u  IPv6   26299      0t0  TCP *:21 (LISTEN)
sshd        1037            root    3u  IPv4   29181      0t0  TCP *:22 (LISTEN)
sshd        1037            root    4u  IPv6   29183      0t0  TCP *:22 (LISTEN)
docker-pr  86081            root    4u  IPv6  520074      0t0  TCP *:8088 (LISTEN)
docker-pr 287023            root    4u  IPv6 1831110      0t0  TCP *:8086 (LISTEN)
docker-pr 318522            root    4u  IPv6 2109586      0t0  TCP *:9440 (LISTEN)
docker-pr 318537            root    4u  IPv6 2110806      0t0  TCP *:8443 (LISTEN)
node      354955           user   18u  IPv4 2274703      0t0  TCP localhost:34575 (LISTEN)

user@myhost:~/d/clickhouse$ netstat -an | grep "LISTEN "
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:34575         0.0.0.0:*               LISTEN     
tcp6       0      0 :::21                   :::*                    LISTEN     
tcp6       0      0 :::8086                 :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::8088                 :::*                    LISTEN     
tcp6       0      0 :::8443                 :::*                    LISTEN     
tcp6       0      0 :::9440                 :::*                    LISTEN 

UPDATE:

on the server I ran sudo tcpdump -ni eth0 port 8443 and then on client machine I ran nc -zv 192.168.1.58 8443:

user@myhost:~$ sudo tcpdump -ni eth0 port 8443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:05:51.368952 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434934937 ecr 0,nop,wscale 7], length 0
15:05:52.380268 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434935948 ecr 0,nop,wscale 7], length 0
15:05:54.460280 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434938028 ecr 0,nop,wscale 7], length 0
15:05:58.540705 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434942109 ecr 0,nop,wscale 7], length 0
15:06:06.940802 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434950509 ecr 0,nop,wscale 7], length 0
15:06:23.581056 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434967149 ecr 0,nop,wscale 7], length 0
15:06:56.221198 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434999788 ecr 0,nop,wscale 7], length 0

and nc failed with the message nc: connect to 192.168.1.58 port 8443 (tcp) failed: Connection timed out

The output of sudo ufw status verbose

user@myhost:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
9440/tcp                   ALLOW IN    Anywhere                  
8443/tcp                   ALLOW IN    Anywhere                  
8443                       ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
9440/tcp (v6)              ALLOW IN    Anywhere (v6)             
8443 (v6)                  ALLOW IN    Anywhere (v6)             
8443/tcp (v6)              ALLOW IN    Anywhere (v6)  

I can connect to service if firewall is disabled:

nc -zv 192.168.1.58 8443 
Connection to 192.168.1.58 8443 port [tcp/*] succeeded!

I can connect to service with IPv4 address if firewall is disabled:
enter image description here


Get this bounty!!!

#StackBounty: #iptables #routing #sip Routing traffic for specific port range

Bounty: 50

I have a Ubiquiti Dream Machine (UDM) which is part of a project that is replacing a network topology with a different one. This involves both Internet traffic and VoIP (Asterisk). During the phased introduction of the new topology, I have the following requirement due to limitations we have when configuring the Asterisk server:

On the UDM I need to re-route all UDP traffic pointed at 10.0.0.1, in ports 50000-55000, to 10.0.10.1 on interface br8

I doubt this can be achieved from the UI, but I have SSH access to the UDM where I can touch up the iptables and ip route configurations.

On the UDM, the routing table is like this:

# ip route
10.0.0.0/24 dev br3 proto kernel scope link src 10.0.0.1
10.0.1.0/24 dev br5 proto kernel scope link src 10.0.1.1
10.0.2.0/24 dev br6 proto kernel scope link src 10.0.2.1
10.0.3.0/24 dev br4 proto kernel scope link src 10.0.3.1
10.0.10.0/24 dev br8 proto kernel scope link src 10.0.10.1
10.1.1.0/24 dev br0 proto kernel scope link src 10.1.1.1
10.2.2.0/24 dev br2 proto kernel scope link src 10.2.2.1
192.168.1.0/24 dev eth4 proto kernel scope link src 192.168.1.86

An important note on topology: the 10.0.10.0/24 network is the one bridging VoIP traffic between the old and the new topologies, The old VoIP server there has the following routing table:

# ip route
192.168.1.248/29 dev eth1  proto kernel  scope link  src 192.168.1.250
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
10.0.1.0/24 dev eth3  proto kernel  scope link  src 10.0.1.1
10.0.10.0/24 dev eth2  proto kernel  scope link  src 10.0.10.10
10.0.0.0/8 via 10.0.10.1 dev eth2
default via 192.168.1.254 dev eth1

Some networks appear conflicted, but they’re not really talking to each other. The only thing talking between these two servers, is VLAN br8 on the UDM which connects to eth2 on the old server, for VoIP traffic only.

The routing is working as I intend it to. VoIP is going through the server at 10.0.10.10, visible from both the old and the new world. When I place a VoIP call, the SIP negotiation happens correctly, meaning that each phone is able to see the server and talk both ways.

My only problem is that when the RTP voice traffic starts flowing, one of the phones sometimes (depending on which party initiates the call) sends it to the old VoIP server address (was 10.0.0.1) instead of to the new one, 10.0.10.10. This happens despite being re-configured to use the new address, and despite having just done the SIP negotiation with the new address! It’s an asterisk configuration problem that sends the wrong address inside the SIP invite, fooling the phone. The Asterisk server thinks it’s all the same because his own identity is both 10.0.0.1 and 10.0.10.10, but that is true only in the old world, not in the new…

So during the one-way audio calls, I see this kind of traffic on the UDM:

# tcpdump -q -n -c 20 -i any host 10.0.10.10 or host 10.0.2.1833 or host 10.0.10.47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
12:20:55.545461 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.545461 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.545461 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.565464 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.565464 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.565464 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.570260 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570260 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570313 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570317 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570764 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570764 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570807 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.570810 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.571077 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.571077 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.571109 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.571111 IP 10.0.2.183.50030 > 10.0.10.10.54736: UDP, length 172
12:20:55.585465 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172
12:20:55.585465 IP 10.0.10.47.5032 > 10.0.0.1.50042: UDP, length 172

The traffic going to 10.0.10.10 is ok, the one going to 10.0.0.1 is not. I’d like to redirect it but I need your help.

(I know a solution could, or even should, be attempted by fixing Asterisk server config somehow, but there are limitations there, and I am charged only with the re-routing solution. Asking about the re-routing is the sole purpose of my question here).

The current iptables configuration on the UDM is this:

# iptables-save
# Generated by iptables-save v1.6.1 on Thu May 13 12:28:34 2021
*nat
:PREROUTING ACCEPT [149794:35652606]
:INPUT ACCEPT [59043:3818189]
:OUTPUT ACCEPT [205240:13204474]
:POSTROUTING ACCEPT [179113:10974505]
:UBIOS_INPUT_JUMP - [0:0]
:UBIOS_OUTPUT_JUMP - [0:0]
:UBIOS_POSTROUTING_JUMP - [0:0]
:UBIOS_POSTROUTING_USER_HOOK - [0:0]
:UBIOS_PREROUTING_JUMP - [0:0]
-A PREROUTING -j UBIOS_PREROUTING_JUMP
-A INPUT -j UBIOS_INPUT_JUMP
-A OUTPUT -j UBIOS_OUTPUT_JUMP
-A POSTROUTING -j UBIOS_POSTROUTING_JUMP
-A UBIOS_POSTROUTING_JUMP -j UBIOS_POSTROUTING_USER_HOOK
-A UBIOS_POSTROUTING_USER_HOOK -o eth4 -m comment --comment 00000001095216660481 -j MASQUERADE
COMMIT
# Completed on Thu May 13 12:28:34 2021
# Generated by iptables-save v1.6.1 on Thu May 13 12:28:34 2021
*mangle
:PREROUTING ACCEPT [21051971:19450922056]
:INPUT ACCEPT [11815594:10852127372]
:FORWARD ACCEPT [9222781:8597163389]
:OUTPUT ACCEPT [11762182:10802741148]
:POSTROUTING ACCEPT [21125153:19406413016]
COMMIT
# Completed on Thu May 13 12:28:34 2021
# Generated by iptables-save v1.6.1 on Thu May 13 12:28:34 2021
*filter
:INPUT ACCEPT [11703464:10819984868]
:FORWARD ACCEPT [9222781:8597163389]
:OUTPUT ACCEPT [11762124:10802734194]
:UBIOS_FORWARD_IN_USER - [0:0]
:UBIOS_FORWARD_JUMP - [0:0]
:UBIOS_FORWARD_OUT_USER - [0:0]
:UBIOS_FORWARD_USER_HOOK - [0:0]
:UBIOS_INPUT_JUMP - [0:0]
:UBIOS_INPUT_USER_HOOK - [0:0]
:UBIOS_IN_GEOIP - [0:0]
:UBIOS_LAN_IN_USER - [0:0]
:UBIOS_LAN_LOCAL_USER - [0:0]
:UBIOS_LAN_OUT_USER - [0:0]
:UBIOS_OUTPUT_JUMP - [0:0]
:UBIOS_OUTPUT_USER_HOOK - [0:0]
:UBIOS_OUT_GEOIP - [0:0]
:UBIOS_WAN_IN_USER - [0:0]
:UBIOS_WAN_LOCAL_USER - [0:0]
:UBIOS_WAN_OUT_USER - [0:0]
-A INPUT -j UBIOS_INPUT_JUMP
-A FORWARD -j UBIOS_FORWARD_JUMP
-A OUTPUT -j UBIOS_OUTPUT_JUMP
-A UBIOS_FORWARD_IN_USER -i eth4 -m comment --comment 00000001095216663481 -j UBIOS_WAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br0 -m comment --comment 00000001095216663482 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br2 -m comment --comment 00000001095216663483 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br3 -m comment --comment 00000001095216663484 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br4 -m comment --comment 00000001095216663485 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br5 -m comment --comment 00000001095216663486 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br6 -m comment --comment 00000001095216663487 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_IN_USER -i br8 -m comment --comment 00000001095216663488 -j UBIOS_LAN_IN_USER
-A UBIOS_FORWARD_JUMP -j UBIOS_FORWARD_USER_HOOK
-A UBIOS_FORWARD_OUT_USER -o eth4 -m comment --comment 00000001095216663481 -j UBIOS_WAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br0 -m comment --comment 00000001095216663482 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br2 -m comment --comment 00000001095216663483 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br3 -m comment --comment 00000001095216663484 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br4 -m comment --comment 00000001095216663485 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br5 -m comment --comment 00000001095216663486 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br6 -m comment --comment 00000001095216663487 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_OUT_USER -o br8 -m comment --comment 00000001095216663488 -j UBIOS_LAN_OUT_USER
-A UBIOS_FORWARD_USER_HOOK -m comment --comment 00000001095216663481 -j UBIOS_FORWARD_IN_USER
-A UBIOS_FORWARD_USER_HOOK -m comment --comment 00000001095216663482 -j UBIOS_FORWARD_OUT_USER
-A UBIOS_INPUT_JUMP -j UBIOS_INPUT_USER_HOOK
-A UBIOS_INPUT_USER_HOOK -i eth4 -m comment --comment 00000001095216663481 -j UBIOS_WAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br0 -m comment --comment 00000001095216663482 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br2 -m comment --comment 00000001095216663483 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br3 -m comment --comment 00000001095216663484 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br4 -m comment --comment 00000001095216663485 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br5 -m comment --comment 00000001095216663486 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br6 -m comment --comment 00000001095216663487 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_INPUT_USER_HOOK -i br8 -m comment --comment 00000001095216663488 -j UBIOS_LAN_LOCAL_USER
-A UBIOS_LAN_IN_USER -d 10.0.10.10/32 -j LOG
-A UBIOS_LAN_IN_USER -d 10.0.10.10/32 -m comment --comment 00000001095216662480 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.10.10/32 -j LOG
-A UBIOS_LAN_IN_USER -s 10.0.10.10/32 -m comment --comment 00000001095216662481 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.2.0/24 -m comment --comment 00000001095216666481 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.3.0/24 -m comment --comment 00000001095216666482 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.1.0/24 -m comment --comment 00000001095216666483 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.2.2.0/24 -m comment --comment 00000001095216666484 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.10.0/24 -m comment --comment 00000001095216666485 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.1.1.0/24 -m comment --comment 00000001095216666486 -j RETURN
-A UBIOS_LAN_IN_USER -s 10.0.0.0/24 -m comment --comment 00000001095216666487 -j RETURN
-A UBIOS_LAN_IN_USER -j LOG
-A UBIOS_LAN_IN_USER -m comment --comment 00000001097364144127 -j RETURN
-A UBIOS_LAN_LOCAL_USER -j LOG
-A UBIOS_LAN_LOCAL_USER -m comment --comment 00000001097364144127 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.0.2.0/24 -m comment --comment 00000001095216666481 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.0.3.0/24 -m comment --comment 00000001095216666482 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.0.1.0/24 -m comment --comment 00000001095216666483 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.2.2.0/24 -m comment --comment 00000001095216666484 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.0.10.0/24 -m comment --comment 00000001095216666485 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.1.1.0/24 -m comment --comment 00000001095216666486 -j RETURN
-A UBIOS_LAN_OUT_USER -d 10.0.0.0/24 -m comment --comment 00000001095216666487 -j RETURN
-A UBIOS_LAN_OUT_USER -j LOG
-A UBIOS_LAN_OUT_USER -m comment --comment 00000001097364144127 -j RETURN
-A UBIOS_WAN_IN_USER -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment 00000001095216663481 -j RETURN
-A UBIOS_WAN_IN_USER -m conntrack --ctstate INVALID -m comment --comment 00000001095216663482 -j DROP
-A UBIOS_WAN_IN_USER -m comment --comment 00000001097364144127 -j DROP
-A UBIOS_WAN_LOCAL_USER -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment 00000001095216663481 -j RETURN
-A UBIOS_WAN_LOCAL_USER -m conntrack --ctstate INVALID -m comment --comment 00000001095216663482 -j DROP
-A UBIOS_WAN_LOCAL_USER -m comment --comment 00000001097364144127 -j DROP
-A UBIOS_WAN_OUT_USER -m comment --comment 00000001097364144127 -j RETURN
COMMIT

I read online about the possibility to do what I intend by:

  • marking the packets to be routed in iptables (using mangle)
  • using a second routing table for those packets (adding to /etc/iproute2/rt_tables)
  • adjusting that table to send stuff where it needs to go

While I understand the general idea, I am no networks specialist, I am new to these concepts and I get lost in the details. I am not sure how to mark, and how much of the main routing table needs to be repeated in the second table. I would appreciate some specific help with these commands and configurations. Thanks in advance!

So, how can I re-route all UDP traffic on the UDM pointed at 10.0.0.1, in ports 50000-55000, to 10.0.10.1 on interface br8?


Get this bounty!!!

#StackBounty: #networking #security #iptables #docker Allow docker container to connect to certain IP addresses only

Bounty: 50

The goal is to create a docker container that can connect only to certain IP addresses (both on the local network that the host belongs to, and on the Internet).

The container itself does not need to be directly accessible or expose any ports.

Example:

  1. Docker host machine 192.168.1.100
  2. Some device on 192.168.1.150 e.g. an IP camera
  3. Some cloud VPS on <static_ip>

— need to create a container that can ssh to <static_ip> and connect to the device 192.168.1.150 but cannot connect to anything else whatsoever (specifically no other containers on the host, nothing else on the 192.168.1.0 network, and perhaps even nothing else on the Internet apart from the VPS).

Note that the host runs other containers with various services on them, and those must not be interfered with.

After some research I found that I probably should create a custom bridge network like this:

docker network create --driver bridge 
-o "com.docker.network.bridge.enable_icc"="false" 
my-restricted-network

and then run the container on that network:

docker run --name my-restricted-container 
--network my-restricted-network 
-d image_name /entrypoint.sh

What do I need to do then? I guess add some iptables rules on the host which will control my-restricted-network only. How exactly?


Get this bounty!!!

#StackBounty: #linux #ip #iptables #forwarding SmartDEN Watchdpg without Internet access over Linux PC with IP forward

Bounty: 50

I explain the assumption:

I have a local network, in which the router functions is done by an industrial Linux PC connected to the internet and a VPN; these are the PC data:

# sysctl -p
net.ipv4.ip_forward = 1
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 00:60:e0:88:82:44 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:60:e0:88:82:44 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global br0
       valid_lft forever preferred_lft forever
    inet 10.2.55.1/24 brd 10.2.55.255 scope global br0
       valid_lft forever preferred_lft forever
    inet 192.168.0.131/24 brd 192.168.0.255 scope global dynamic br0
       valid_lft 42358sec preferred_lft 42358sec
    inet6 fdd9:cbf6:173c::5e4/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fdd9:cbf6:173c:0:260:e0ff:fe88:8244/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::260:e0ff:fe88:8244/64 scope link 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.2.0.44/16 brd 10.2.255.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::3c21:dab6:295d:15a9/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:95:01:f1:39 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

The local address we use on the PC both to connect to it via the VPN and to connect to the local network is 10.2.55.1 (br0).

On the network, I have an Ippower (SmartDEN IP-Watchdog), to restart computers according to circumstances. Their address is 10.2.55.11.

the ping between both is correct, and in its configuration, by not pinging the ippower with the PC, it is restarted.

I want to do the same with a switch connected directly to the ippower, with the rule that, if there is no internet (ping to 8.8.8.8 or 1.1.1.1), restart the router; but the ippower has no internet outlet, while the PC does. When I try the ping to 8.8.8.8 in the web service’s ippower, I get:

Ping/HTTP Test Result to 8.8.8.8: Timed out

When I ping through the interfaces, I get that I only ping through br0:

# ping -I enp1s0 8.8.8.8
ping: Warning: source address might be selected on device other than: enp1s0
PING 8.8.8.8 (8.8.8.8) from 192.168.100.1 enp1s0: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10218ms


# ping -I br0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.0.131 br0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=7.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=6.60 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=114 time=6.60 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.597/6.740/7.024/0.200 ms


# ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.2.0.44 tun0: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2026ms

What iptables rules would be appropriate for the forwarded networked element to have internet output? is there another better way to do it?


Get this bounty!!!