How to disable Firewall

Hi,

i have set up openvpn server on my opensuse machine in lan…
The router forwards to the lan ip and should work because i have running it on a debian machine.
But on opensuse it doesent work at all… If i nmap from lan the vpn ports it shows them filtered, same whit vnc… Only ssh and samba are accessible… Than i have tried to switch off the firewall but nothing changes… Iptables reports all rules unloaded…
I have set up the vpn according to this tutorail.
I know that masquerading needs the firewall but why the ports are filtered even if the firewall is disabled.

# Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017*nat
:PREROUTING ACCEPT [32:4478]
:INPUT ACCEPT [19:2189]
:OUTPUT ACCEPT [3:421]
:POSTROUTING ACCEPT [3:421]
COMMIT
# Completed on Tue Feb 21 10:47:28 2017
# Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017
*raw
:PREROUTING ACCEPT [1048:65498]
:OUTPUT ACCEPT [1018:367305]
COMMIT
# Completed on Tue Feb 21 10:47:28 2017
# Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017
*filter
:INPUT ACCEPT [1030:63069]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1018:367305]
COMMIT



netstat

Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      0          19987      1656/cupsd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      0          22179      1936/smbd
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      0          22180      1936/smbd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          20911      1778/sshd
tcp        0      0 :::445                  :::*                    LISTEN      0          22177      1936/smbd
tcp        0      0 :::139                  :::*                    LISTEN      0          22178      1936/smbd
tcp        0      0 :::1716                 :::*                    LISTEN      1000       29796      2842/kdeconnectd
tcp        0      0 :::22                   :::*                    LISTEN      0          20913      1778/sshd
udp        0      0 0.0.0.0:36540           0.0.0.0:*                           483        19060      1178/avahi-daemon:
udp        0      0 10.0.0.1:123            0.0.0.0:*                           74         21959      1784/ntpd
udp        0      0 192.168.1.10:123        0.0.0.0:*                           0          20921      1784/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           0          20919      1784/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           0          20915      1784/ntpd
udp        0      0 192.168.1.255:137       0.0.0.0:*                           0          23163      1886/nmbd
udp        0      0 192.168.1.10:137        0.0.0.0:*                           0          23162      1886/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           0          23152      1886/nmbd
udp        0      0 192.168.1.255:138       0.0.0.0:*                           0          23165      1886/nmbd
udp        0      0 192.168.1.10:138        0.0.0.0:*                           0          23164      1886/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           0          23153      1886/nmbd
udp        0      0 0.0.0.0:1194            0.0.0.0:*                           0          22979      1781/openvpn
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           483        19058      1178/avahi-daemon:
udp        0      0 :::1716                 :::*                                1000       29795      2842/kdeconnectd
udp        0      0 :::52956                :::*                                483        19061      1178/avahi-daemon:
udp        0      0 :::123                  :::*                                0          22989      1784/ntpd
udp        0      0 :::5353                 :::*                                483        19059      1178/avahi-daemon:



ip addr


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1    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
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 18:66:da:38:76:61 brd ff:ff:ff:ff:ff:ff
3: p1p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 00:15:17:90:1d:6f brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 00:15:17:70:19:a4 brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:15:17:70:19:a4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.0.0.1 peer 10.0.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever



This is only an answer to your thread title (I did not read the post).

YaST > System > Services Manager. Scroll down to SuSEfirewall2. Select the two entries one by one and use the buttons below to Stop and Disable (to prevent start on boot) them.

OR

YaST > SEcurity and Users > Firewall. On the first screen yyou can Enable/Disable.

In other words: On openSUSE is YaST your friend for system management.

1 Like

On 02/21/2017 02:56 AM, o5i wrote:
>
> i have set up openvpn server on my opensuse machine in lan…
> The router forwards to the lan ip and should work because i have running
> it on a debian machine.
> But on opensuse it doesent work at all… If i nmap from lan the vpn
> ports it shows them filtered, same whit vnc… Only ssh and samba are
> accessible… Than i have tried to switch off the firewall but nothing
> changes… Iptables reports all rules unloaded…
> I have set up the vpn according to 'this ’ (http://tinyurl.com/zkevgt7)
> tutorail.
> I know that masquerading needs the firewall but why the ports are
> filtered even if the firewall is disabled.
>
>
>
> Code:
> --------------------
> # Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017*nat
> :PREROUTING ACCEPT [32:4478]
> :INPUT ACCEPT [19:2189]
> :OUTPUT ACCEPT [3:421]
> :POSTROUTING ACCEPT [3:421]
> COMMIT
> # Completed on Tue Feb 21 10:47:28 2017
> # Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017
> *raw
> :PREROUTING ACCEPT [1048:65498]
> :OUTPUT ACCEPT [1018:367305]
> COMMIT
> # Completed on Tue Feb 21 10:47:28 2017
> # Generated by iptables-save v1.4.21 on Tue Feb 21 10:47:28 2017
> *filter
> :INPUT ACCEPT [1030:63069]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [1018:367305]
> COMMIT

The rules shown above mean nothing more or less than “anything can go
anywhere” so the host-based firewall is not blocking things. If you want
to see traffic as it flows, run tcpdump which will show traffic regardless
of the firewall rules, meaning that even if the firewall blocks something,
tcpdump on that same box will show the attempts.


/usr/sbin/tcpdump -n -s 0 -i any

If you do that and try nmap, and you do not see anything, then look at
your network to see what else may be blocking your traffic from ever
reaching your box. If you run that and you see the packets getting to
your box, but you see no responses, then that will be a bit odd since, as
mentioned before, your fireawll rules are wide open (anything can go
anywhere).

It sounds like your Debian-based box may be at fault, since it’s probably
the smartest box between your client (openvpn/nmap) and server (openSUSE).


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Hi,
i opened a vnc port for the libvirt host and tried to connect using a windows vnc client trough the vpn on the debian box to the vnc guest vm on the suse box but it doesent work…
But the network works, i ever had problems whit other systems…
Nmap from debian to suse reports also ports filtered, from localhost to lan ip it works, and of course localhost to localhost too…
Here is the output of tcpdump


13:45:52.681476 IP 192.168.1.10.22 > 192.168.1.2.55766: Flags [P.], seq 3207589126:3207589322, ack 2972508075, win 279, length 196
13:45:52.681487 IP 192.168.1.10.22 > 192.168.1.2.55766: Flags [P.], seq 0:196, ack 1, win 279, length 196
13:45:52.706184 IP 192.168.1.2.55766 > 192.168.1.10.22: Flags .], ack 0, win 254, length 0
13:45:52.706184 IP 192.168.1.2.55766 > 192.168.1.10.22: Flags .], ack 0, win 254, length 0
13:45:52.772240 IP 192.168.1.2.55766 > 192.168.1.10.22: Flags .], ack 196, win 253, length 0
13:45:52.772240 IP 192.168.1.2.55766 > 192.168.1.10.22: Flags .], ack 196, win 253, length 0
13:45:53.520184 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:53.520193 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:53.520184 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:54.518194 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:54.518203 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:54.518194 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:55.518165 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:55.518174 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:55.518165 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:58.256352 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:58.256364 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:58.256352 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:58.892289 IP 192.168.1.203.5060 > 224.0.1.75.5060: SIP, length: 635
13:45:59.253178 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:59.253187 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:45:59.253178 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:00.253180 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:00.253189 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:00.253180 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:02.992227 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:02.992236 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:02.992227 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:03.988163 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:03.988182 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:03.988163 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:04.988156 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:04.988166 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:04.988156 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:04.993471 IP 192.168.1.1 > 224.0.0.1: igmp query v2 [max resp time 10]
13:46:04.993490 IP 192.168.1.1 > 224.0.0.1: igmp query v2 [max resp time 10]
13:46:04.993471 IP 192.168.1.1 > 224.0.0.1: igmp query v2 [max resp time 10]
13:46:05.052777 IP 192.168.1.10 > 224.0.0.251: igmp v2 report 224.0.0.251
13:46:05.052784 IP 192.168.1.10 > 224.0.0.251: igmp v2 report 224.0.0.251
13:46:05.757952 IP 192.168.1.201 > 239.2.0.252: igmp v2 report 239.2.0.252
13:46:07.728192 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:07.728204 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:07.728192 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:08.723157 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:08.723166 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:08.723157 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:09.723137 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:09.723149 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:09.723137 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:12.464084 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:12.464100 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:12.464084 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:12.568089 IP 192.168.1.111 > 239.255.255.250: igmp v1 report 239.255.255.250
13:46:12.768096 IP 192.168.1.111 > 224.0.0.251: igmp v1 report 224.0.0.251
13:46:13.463106 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:13.463118 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:13.463106 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:14.463114 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:14.463123 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:14.463114 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:17.200197 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:17.200206 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:17.200197 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:18.198110 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:18.198119 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:18.198110 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:19.198096 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:19.198105 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:19.198096 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:19.478929 ARP, Request who-has 192.168.1.10 tell 192.168.1.2, length 46
13:46:19.478929 ARP, Request who-has 192.168.1.10 tell 192.168.1.2, length 46
13:46:19.478942 ARP, Reply 192.168.1.10 is-at 00:15:17:70:19:a4, length 28
13:46:19.478945 ARP, Reply 192.168.1.10 is-at 00:15:17:70:19:a4, length 28
13:46:21.936380 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:21.936398 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:21.936380 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:22.933076 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:22.933091 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:22.933076 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:23.933068 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:23.933077 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:23.933068 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:26.672248 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:26.672257 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:26.672248 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:27.668076 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:27.668088 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46
13:46:27.668076 ARP, Request who-has 192.168.1.205 tell 192.168.1.1, length 46


nmap -sS 192.168.1.10 -p 5900


Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-20 02:09 CET
Nmap scan report for 192.168.1.10
Host is up (0.00060s latency).
PORT     STATE    SERVICE
5900/tcp filtered vnc
MAC Address: 00:15:17:70:19:A4 (Intel Corporate)


Nmap done: 1 IP address (1 host up) scanned in 0.80 seconds

Are there maybee some problems because i have set up a static ip and gateway?
Before i set up gateway on yast network route there was no access to the internet even if i had dns servers set


cat /etc/sysconfig/network/ifcfg-br0
BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='em1 p1p1 p2p1'
BRIDGE_STP='off'
BROADCAST=''
DHCLIENT_SET_DEFAULT_ROUTE='yes'
ETHTOOL_OPTIONS=''
IPADDR='192.168.1.10/24'
MTU=''
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
NAME=''




cat /etc/sysconfig/network/config  | grep -vv '#' | grep -vv ^$CHECK_DUPLICATE_IP="yes"
SEND_GRATUITOUS_ARP="auto"
DEBUG="no"
WAIT_FOR_INTERFACES="30"
FIREWALL="yes"
NM_ONLINE_TIMEOUT="30"
NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime"
NETCONFIG_VERBOSE="no"
NETCONFIG_FORCE_REPLACE="no"
NETCONFIG_DNS_POLICY="auto"
NETCONFIG_DNS_FORWARDER="resolver"
NETCONFIG_DNS_FORWARDER_FALLBACK="yes"
NETCONFIG_DNS_STATIC_SEARCHLIST=""
NETCONFIG_DNS_STATIC_SERVERS="192.168.1.1 8.8.8.8 8.8.4.4"
NETCONFIG_DNS_RANKING="auto"
NETCONFIG_DNS_RESOLVER_OPTIONS=""
NETCONFIG_DNS_RESOLVER_SORTLIST=""
NETCONFIG_NTP_POLICY="auto"
NETCONFIG_NTP_STATIC_SERVERS=""
NETCONFIG_NIS_POLICY="auto"
NETCONFIG_NIS_SETDOMAINNAME="yes"
NETCONFIG_NIS_STATIC_DOMAIN=""
NETCONFIG_NIS_STATIC_SERVERS=""
WIRELESS_REGULATORY_DOMAIN=''
AUTO6_WAIT_AT_BOOT=""
AUTO6_UPDATE=""
LINK_REQUIRED="auto"
WICKED_DEBUG=""
WICKED_LOG_LEVEL=""


sysctl.conf
####
#
# /etc/sysctl.conf is meant for local sysctl settings
#
# sysctl reads settings from the following locations:
#   /boot/sysctl.conf-<kernelversion>
#   /lib/sysctl.d/*.conf
#   /usr/lib/sysctl.d/*.conf
#   /usr/local/lib/sysctl.d/*.conf
#   /etc/sysctl.d/*.conf
#   /run/sysctl.d/*.conf
#   /etc/sysctl.conf
#
# To disable or override a distribution provided file just place a
# file with the same name in /etc/sysctl.d/
#
# See sysctl.conf(5), sysctl.d(5) and sysctl(8) for more information
#
####


net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0



This is the output on the debian machine


cat dump | grep 5900
02:30:43.765345 IP 10.0.0.6.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:43.765361 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:43.765364 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:46.765846 IP 10.0.0.6.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:46.765855 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:46.765858 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,wscale 8,nop,nop,sackOK], length 0
02:30:52.766588 IP 10.0.0.6.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,nop,sackOK], length 0
02:30:52.766599 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,nop,sackOK], length 0
02:30:52.766602 IP 192.168.1.2.55937 > 192.168.1.10.5900: Flags [S], seq 2645447744, win 8192, options [mss 1368,nop,nop,sackOK], length 0
02:30:57.153103 IP 192.168.1.1.80 > 192.168.1.2.55943: Flags [S.], seq 1361343433, ack 1450745900, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
02:30:57.153103 IP 192.168.1.1.80 > 10.0.0.6.55943: Flags [S.], seq 1361343433, ack 1450745900, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
02:30:57.153111 IP 192.168.1.1.80 > 10.0.0.6.55943: Flags [S.], seq 1361343433, ack 1450745900, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0



It looks like the suse machine doesent recieve nothing…

Agreed; the tcpdump from your openSUSE box shows nothing on TCP 5900, so
it is not seeing anything. This is likely NOT because of a bad gateway on
the openSUSE box, since a bad gateway would probably still allow packets
to get in but would have a problem returning them. Still, post the output
the following command to verify:


ip route  #or just 'ip r'

What is interesting about the output below is that something appears to be
sending data to your openSUSE box via two different IPs, and from the same
port on each of those IPs (10.0.0.6 and 192.168.1.2). I presume these are
different addresses bound to your Debian box, and maybe it is a quirk of
tcpdump where it shows what I presume is the VPN IP address (10.0.0.6) and
the local LAN address (192.168.1.2) with the packet going out on the exact
same port. Interesting, or weird, but still interesting.

As a tiny note, I presume you had a ton of output because you are SSH’d
into the box; to avoid that you can add something like ‘not port 22’ to
your tcpdump command to have it show everything that is NOT on port 22.
Alternatively if you wan to only watch a certain port (less-advisable
because you miss other important things like DNS/ARP) you could give
tcpdump a whitelist, rather than a blacklist, with something like ‘port 5900’.


/usr/sbin/tcpdump -n -s 0 -i any not port 22  #filter out SSH (presumably)
/usr/sbin/tcpdump -n -s 0 -i any port 5900    #only show VNC (presumably)

It may be worthwhile to view the routing information from the Debian box
too as I now gather thatn it is the VPN box or something. A big
description of your entire network may also be in order. Trying these
same connections (VNC) without the VPN being involved may also help. For
example, if the concern is whether or not packets can get from the Debian
box to the openSUSE box, you could SSH to the Debian box from your client
system and then forward a port through to your openSUSE box, which would
allow you to test the VNC traffic from Debian to openSUSE without using
the VPN.

From a client machine (presumably Linux):


#Make an SSH connection from the client machine to the Debian box which I
#presume is on, and accessible by, 10.0.0.6
ssh -L 5900:192.168.1.10:5900 10.0.0.6

#Next connect your VNC client to the 'localhost' to use the SSH tunnel:
vncviewer localhost::5900

What SHOULD happen is that your VNC client connects to a new listening
socket on your SSH client machine, and then the SSH connection forwards
all of those packets through the tunnel to the destination (Debian) side
where it then drops the packets on the wire for the configured destination
(192.168.1.10:5900). Getting tcpdump output from the Debian and openSUSE
boxes may be useful to see if the packets make it where desired.


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Hi

Lots of infos… thx
lests start
About the network, its just a small homenet, a router whit 1 additional switch and the debian and opensuse box attached…
I wanted to replace the debian box whit the suse one but openvpn doesent work so i cant shut down that machine…
There are other stuff like voip printer and phone attached too but doesent matter…


ip route
default via 192.168.1.1 dev br0
10.0.0.0/24 via 10.0.0.2 dev tun0
10.0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.10

I tried to nmap from a virtual machine wich is attached to br0 but shows up as vnet0 on ifconfig… whatever it works…


/usr/sbin/tcpdump -n -s 0 -i any port 5900    #only show VNC (presumably)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:31:36.980038 IP 192.168.1.209.59175 > 192.168.1.10.5900: Flags [S], seq 1715555948, win 1024, options [mss 1460], length 0
17:31:36.980038 IP 192.168.1.209.59175 > 192.168.1.10.5900: Flags [S], seq 1715555948, win 1024, options [mss 1460], length 0
17:31:36.980080 IP 192.168.1.10.5900 > 192.168.1.209.59175: Flags [S.], seq 2284411912, ack 1715555949, win 29200, options [mss 1460], length 0
17:31:36.980083 IP 192.168.1.10.5900 > 192.168.1.209.59175: Flags [S.], seq 2284411912, ack 1715555949, win 29200, options [mss 1460], length 0
17:31:36.980178 IP 192.168.1.209.59175 > 192.168.1.10.5900: Flags [R], seq 1715555949, win 0, length 0
17:31:36.980178 IP 192.168.1.209.59175 > 192.168.1.10.5900: Flags [R], seq 1715555949, win 0, length 0
17:31:37.080193 IP 192.168.1.209.59176 > 192.168.1.10.5900: Flags [S], seq 1715490413, win 1024, options [mss 1460], length 0
17:31:37.080193 IP 192.168.1.209.59176 > 192.168.1.10.5900: Flags [S], seq 1715490413, win 1024, options [mss 1460], length 0
17:31:37.080239 IP 192.168.1.10.5900 > 192.168.1.209.59176: Flags [S.], seq 4272240148, ack 1715490414, win 29200, options [mss 1460], length 0
17:31:37.080242 IP 192.168.1.10.5900 > 192.168.1.209.59176: Flags [S.], seq 4272240148, ack 1715490414, win 29200, options [mss 1460], length 0
17:31:37.080336 IP 192.168.1.209.59176 > 192.168.1.10.5900: Flags [R], seq 1715490414, win 0, length 0
17:31:37.080336 IP 192.168.1.209.59176 > 192.168.1.10.5900: Flags [R], seq 1715490414, win 0, length 0

For the other stuff i need to set up a third linux box, maybee a virtual machine… I will report later…

What is interesting about the output below is that something appears to be
sending data to your openSUSE box via two different IPs, and from the same
port on each of those IPs (10.0.0.6 and 192.168.1.2). I presume these are
different addresses bound to your Debian box, and maybe it is a quirk of
tcpdump where it shows what I presume is the VPN IP address (10.0.0.6) and
the local LAN address (192.168.1.2) with the packet going out on the exact
same port. Interesting, or weird, but still interesting.

I think because the debian box is my gateway to the network where i am connecting to. Im on the machine remotely for now…

Just to be sure we’re on the same page, by default (at least in the past)
openvpn uses UDP; are you sure that your tests of the port are valid?
I’ve never had great luck with UDP-based port tests because, unlike TCP,
they’re not meant to be reliable, so you may get nothing back if the
packet is junk. Just a thought.

Also, I already see the ‘tun0’ device in there; what is that from if not a
VPN something-or-another?

It may help to verify your openvpn setup on the openSUSE box. For
example, do you see the socket listening on the openSUSE box?


sudo /usr/sbin/ss -planetou | grep 1194 #or whatever port openvpn uses

Posting your opevpn.conf file may also be interesting.

After that, tcpdump of the openvpn port as the client (where is the
client?) tries to connect may be useful. I presume you’ll want to VPN
into the openSUSE box from outside your network, meaning your router needs
to forward a port as it may already do for the Debian box. Make sure
that’s a UDP port, if applicable; using UDP is generally better for things
like openvpn, but many tools that do port forwarding assume TCP, and many
tools that test network connections (nmap/netcat) are better at testing
TCP because of characteristics inherent in the protocol. Other tests may
have you try things like ICMP (ping) because they’re easy and we know
them, even though they are invalid for most situations, even those limited
to layer three (3).


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Its not just about openvpn, i have problems whit vnc (libvirt qemu) too… That should be 5900 tcp… Openvpn connects to tun0… But the socket should listen on br0 in my setup…

Strange thing is that i can connect to samba and ssh but not to vnc/spice or openvpn… I can try whit other stuff but i think there is something wrong…

What about ipv6 and hostnames?

From opensuse:


127.0.0.1       localhost
# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
192.168.1.10    linux-o7rv.suse linux-o7rv


udp    UNCONN     0      0         *:1194                  *:*                   users:(("openvpn",pid=1574,fd=5)) ino:21737 sk:b <->
tcp    LISTEN     0      128       *:5900                  *:*                   users:(("qemu-system-x86",pid=2874,fd=17)) uid:479 ino:39219 sk:1b <->
tcp    LISTEN     0      128       *:22                    *:*                   users:(("sshd",pid=1569,fd=3)) ino:19234 sk:14 <->
tcp    ESTAB      0      0      192.168.1.10:22                 192.168.1.2:58830               users:(("sshd",pid=2180,fd=3)) timer:(keepalive,107min,0) ino:28892 sk:15 <->
tcp    LISTEN     0      128      :::22                   :::*                   users:(("sshd",pid=1569,fd=4)) ino:19236 sk:18 v6only:1 <->
tcp    LISTEN     0      50        *:139                   *:*                   users:(("smbd",pid=1648,fd=38)) ino:21971 sk:13 <->
tcp    LISTEN     0      50       :::139                  :::*                   users:(("smbd",pid=1648,fd=36)) ino:21969 sk:17 v6only:1 <->


nmap -sS -p- localhost


Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-22 08:28 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000030s latency).
Not shown: 65529 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
631/tcp  open  ipp
1716/tcp open  unknown
5900/tcp open  vnc


Nmap done: 1 IP address (1 host up) scanned in 4.98 seconds


nmap -sU -p 1-5000 localhost


Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-22 08:25 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 4995 closed ports
PORT     STATE         SERVICE
123/udp  open          ntp
137/udp  open          netbios-ns
138/udp  open|filtered netbios-dgm
1194/udp open|filtered openvpn
1716/udp open|filtered unknown


Nmap done: 1 IP address (1 host up) scanned in 100.79 seconds




netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      0          19222      1540/cupsd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      0          21970      1648/smbd
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      0          21971      1648/smbd
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      479        48417      3057/qemu-system-x8
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          19234      1569/sshd
tcp        0      0 :::445                  :::*                    LISTEN      0          21968      1648/smbd
tcp        0      0 :::139                  :::*                    LISTEN      0          21969      1648/smbd
tcp        0      0 :::1716                 :::*                    LISTEN      1000       32044      2513/kdeconnectd
tcp        0      0 :::22                   :::*                    LISTEN      0          19236      1569/sshd
udp        0      0 10.0.0.1:123            0.0.0.0:*                           74         21990      1587/ntpd
udp        0      0 192.168.1.10:123        0.0.0.0:*                           0          19260      1587/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           0          19258      1587/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           0          19254      1587/ntpd
udp        0      0 192.168.1.255:137       0.0.0.0:*                           0          19306      1603/nmbd
udp        0      0 192.168.1.10:137        0.0.0.0:*                           0          19305      1603/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           0          19294      1603/nmbd
udp        0      0 192.168.1.255:138       0.0.0.0:*                           0          19308      1603/nmbd
udp        0      0 192.168.1.10:138        0.0.0.0:*                           0          19307      1603/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           0          19295      1603/nmbd
udp        0      0 0.0.0.0:1194            0.0.0.0:*                           0          21737      1574/openvpn
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           483        17773      1161/avahi-daemon:
udp        0      0 0.0.0.0:56699           0.0.0.0:*                           483        17775      1161/avahi-daemon:
udp        0      0 :::42617                :::*                                483        17776      1161/avahi-daemon:
udp        0      0 :::1716                 :::*                                1000       32043      2513/kdeconnectd
udp        0      0 :::123                  :::*                                0          19243      1587/ntpd
udp        0      0 :::5353                 :::*                                483        17774      1161/avahi-daemon:

from debian only vnc is filtered but if i do the same on opensuse its not
wtf


Nmap scan report for 192.168.1.10
Host is up (0.00033s latency).
Not shown: 5995 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
139/tcp  open     netbios-ssn
445/tcp  open     microsoft-ds
1716/tcp open     unknown
5900/tcp filtered vnc
MAC Address: 00:15:17:70:19:A4 (Intel Corporate)


Nmap done: 1 IP address (1 host up) scanned in 368.32 seconds



Guess what, i got it!!
The problem was the vpro remote management connected to the ethernet controller. I removed the interface from the bridge and added 2 physical interfaces. Now everything works how it should.

Great feedback; thank-you for sharing your results.


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…