Thread Info
  • State Not Answered
  • Replies 5 replies
  • Subscribers 0 subscribers
  • Views 1339 views
  • Users 0 members are here
Options
Suggested

[7.910][BUG][FIXED] Ports not open through SSL Site to Site

dskillin 
qs-firewall:/root # iptables -t nat --list | grep ssh

NFLOG      tcp  --  anywhere             qs-firewall         tcp spts:tcpmux:65535 dpt:ssh LOGMARK match 60021 

DNAT       tcp  --  anywhere             qs-firewall         tcp spts:tcpmux:65535 dpt:ssh to:192.168.50.2:22 

NFLOG      tcp  --  anywhere             qs-firewall         tcp spts:tcpmux:65535 dpt:ssh LOGMARK match 60021 

DNAT       tcp  --  anywhere             qs-firewall         tcp spts:tcpmux:65535 dpt:ssh to:192.168.50.2:22 

qs-firewall:/root # iptables --list | grep ssh

CONFIRMED  tcp  --  anywhere             192.168.50.2        tcp spts:tcpmux:65535 dpt:ssh ctorigdst qs-firewall 

CONFIRMED  tcp  --  192.168.50.0/24      anywhere            tcp spts:tcpmux:65535 multiport dports ms-wbt-server,5900,ms-wbt-server,5900,ssh,telnet,ica 

CONFIRMED  tcp  --  192.168.50.0/24      10.0.0.0/24         tcp spts:tcpmux:65535 dpt:ssh 

CONFIRMED  tcp  --  10.0.0.0/24          anywhere            tcp spts:tcpmux:65535 multiport dports smtps,imaps,http-alt,rsync,http,jabber-client,imap,ndl-aas,https,ssh,ftp,smtp 

qs-firewall:/root # 


I'm able to connect to the 192.168.50.2 through the public IP across DNAT with SSH.  I am not able to connect to the SSH service by internal IP through the VPN.  The box is able to be pinged. 


dskillin@gitidev ~ $ ping 192.168.50.2 -c 5

PING 192.168.50.2 (192.168.50.2) 56(84) bytes of data.

64 bytes from 192.168.50.2: icmp_seq=1 ttl=61 time=32.3 ms

64 bytes from 192.168.50.2: icmp_seq=2 ttl=61 time=70.5 ms

64 bytes from 192.168.50.2: icmp_seq=3 ttl=61 time=33.1 ms

64 bytes from 192.168.50.2: icmp_seq=4 ttl=61 time=76.2 ms

64 bytes from 192.168.50.2: icmp_seq=5 ttl=61 time=33.9 ms



--- 192.168.50.2 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4020ms

rtt min/avg/max/mdev = 32.338/49.254/76.274/19.815 ms


Traceroute shows the route is known. 


dskillin@gitidev ~ $ sudo traceroute 192.168.50.2     

traceroute to 192.168.50.2 (192.168.50.2), 30 hops max, 38 byte packets

 1  192.168.210.1 (192.168.210.1)  0.810 ms  0.396 ms  1.462 ms

 2  firewall (192.168.254.254)  0.936 ms  0.983 ms  1.461 ms

 3  10.242.2.6 (10.242.2.6)  35.307 ms  35.144 ms  35.811 ms

 4  192.168.50.2 (192.168.50.2)  31.743 ms  33.179 ms *


Pings work in the opposite direction as well. 


dskillin@optimus ~ $ ping 192.168.210.8 -c 5

PING 192.168.210.8 (192.168.210.8) 56(84) bytes of data.

64 bytes from 192.168.210.8: icmp_seq=1 ttl=61 time=32.0 ms

64 bytes from 192.168.210.8: icmp_seq=2 ttl=61 time=32.6 ms

64 bytes from 192.168.210.8: icmp_seq=3 ttl=61 time=36.5 ms

64 bytes from 192.168.210.8: icmp_seq=4 ttl=61 time=33.1 ms

64 bytes from 192.168.210.8: icmp_seq=5 ttl=61 time=34.4 ms



--- 192.168.210.8 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4010ms

rtt min/avg/max/mdev = 32.015/33.775/36.581/1.620 ms

Packets are dropped in the packet filter. 


21:17:16	Default DROP	TCP	

192.168.210.8	:	40655

→	

192.168.50.2	:	22

[SYN]	len=60	ttl=61	tos=0x00	srcmac=0:c:29:ac:a6:50



21:17:19	Default DROP	TCP	

192.168.210.8	:	40655

→	

192.168.50.2	:	22

[SYN]	len=60	ttl=61	tos=0x00	srcmac=0:c:29:ac:a6:50


Automatic packet filter rules are established for the link.

Client side 10.0.0.0/24 & 192.168.50.0/24
Server side 192.168.100.0/24, 192.168.210.0/24, 192.168.251.0/24, & 192.168.120.0/24

This works in previous stable versions.

SSH is enabled on the Astaro, using an alternate port.
  • 0 
    Astaro Beta Report

    --------------------------------

    Version: 7.910

    Type: BUG

    State: CLOSED/FIXED

    Reporter: dskillin+

    Contributor: 

    MantisID: 13687

    Target version: 7.912

    Fixed in version: 7.912

    --------------------------------
  • 0
    The same is happening on additional ports.  I could publish this with WAF, but I shouldn't need to with a VPN connection.

    Pings and traces are working to both remote networks. 


    11:51:17	Default DROP	TCP	

    192.168.251.57	:	59988

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50

    11:51:18	Default DROP	TCP	

    192.168.251.57	:	59989

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50

    11:51:33	Default DROP	TCP	

    192.168.251.57	:	59988

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50

    11:51:34	Default DROP	TCP	

    192.168.251.57	:	59989

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50

    11:52:05	Default DROP	TCP	

    192.168.251.57	:	59988

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50

    11:52:06	Default DROP	TCP	

    192.168.251.57	:	59989

    →	

    192.168.50.2	:	8000

    [SYN]	len=48	ttl=62	tos=0x00	srcmac=0:c:29:ac:a6:50




    aurora:~ dskillin$ ping -c 1 10.0.0.101

    PING 10.0.0.101 (10.0.0.101): 56 data bytes

    64 bytes from 10.0.0.101: icmp_seq=0 ttl=62 time=35.164 ms

    

    --- 10.0.0.101 ping statistics ---

    1 packets transmitted, 1 packets received, 0.0% packet loss

    round-trip min/avg/max/stddev = 35.164/35.164/35.164/0.000 ms

    

    

    aurora:~ dskillin$ ping -c 1 192.168.50.2

    PING 192.168.50.2 (192.168.50.2): 56 data bytes

    64 bytes from 192.168.50.2: icmp_seq=0 ttl=62 time=33.696 ms

    

    --- 192.168.50.2 ping statistics ---

    1 packets transmitted, 1 packets received, 0.0% packet loss

    round-trip min/avg/max/stddev = 33.696/33.696/33.696/0.000 ms




    aurora:~ dskillin$ traceroute 10.0.0.101

    traceroute to 10.0.0.101 (10.0.0.101), 64 hops max, 52 byte packets

     1  192.168.251.1 (192.168.251.1)  3.114 ms  2.242 ms  1.504 ms

     2  10.242.2.6 (10.242.2.6)  33.487 ms  32.943 ms  59.077 ms

     3  10.0.0.101 (10.0.0.101)  50.272 ms  32.990 ms  32.945 ms

    

      

    aurora:~ dskillin$ traceroute 192.168.50.2

    traceroute to 192.168.50.2 (192.168.50.2), 64 hops max, 52 byte packets

     1  192.168.251.1 (192.168.251.1)  2.987 ms  1.509 ms  1.799 ms

     2  10.242.2.6 (10.242.2.6)  35.017 ms  32.990 ms  34.031 ms

     3  192.168.50.2 (192.168.50.2)  35.770 ms  37.082 ms *
  • 0
    Seems there's a bug in the SSL VPN client code for writing the packetfilter rules. Could you please verify by checking if your subnets are missing in the ouput of `iptables -nvL AUTO_FORWARD`
  • 0
    Nevermind, found the bug and fixed it. Should be resolved in the next update.