Guest User!

You are not Sophos Staff.

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

[9.080][BUG] SSLVPN stops working

Johannes Hiby
Hi,

after update from 9.075 to 9.080 the SSLVPN came up but only ping works through
the tunnel. No other protocols work any more.

Autopacket filter is on both sides, ASG 220 with 9.005-16 on other side.

I have removed autopacket filter on both sides and made Firewall rules, same thing.

I have deleted the tunnel and made a new connection, no luck.
Ping works every time but nothing other.


--Johannes
  • 0
    home (v9.090)
    tun0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
        inet 10.242.2.38 peer 10.242.2.37/32 scope global tun0

    office (v9.006)
    tun0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
        inet 10.242.2.1 peer 10.242.2.2/32 scope global tun0

    Firewalllog:
    15:44:54 Default DROP TCP 10.242.2.38:46153 → 10.2.120.245:22 [SYN] len=60 ttl=62 tos=0x00 srcmac=0:1a:8c:32:ea:48
  • 0 in reply to Johannes Hiby

    15:44:54 Default DROP TCP 10.242.2.38:46153 → 10.2.120.245:22 [SYN] len=60 ttl=62 tos=0x00 srcmac=0:1a:8c:32:ea:48


    I think there's your problem. The packets you send through your home UTM seem to get SNATed to the virtual pool IP adress the client has assigned (I assume you did not specify the SSL VPN pool network as a remote network for the site-to-site connection).

    While it could be other things causing this, I'd like to ask you to check your Masquerading settings on your home UTM first. If you know how to, you could also run tcpdump on tun0 on the office UTM to check that the SSH packets go through openvpn. You should see 10.242.2.38 → 10.2.120.245:22 there, where in fact it should be something like HOME_CLIENT_IP → 10.2.120.245:22.
  • 0 in reply to d12fk
    Hi,

    yes i see 10.242.2.38 → 10.2.120.245:22 with tcpdump -n -i tun0 on the home side and office side.
    But i have no nat rule for that.



    gate:/home/login # iptables -n -t nat --list 
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination         
    AUTO_PRE   all  --  0.0.0.0/0            0.0.0.0/0           
    USR_PRE    all  --  0.0.0.0/0            0.0.0.0/0           
    LOAD_BALANCING  all  --  0.0.0.0/0            0.0.0.0/0           

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    AUTO_OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           
    USR_OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           

    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination         
    AUTO_POST  all  --  0.0.0.0/0            0.0.0.0/0           
    USR_POST   all  --  0.0.0.0/0            0.0.0.0/0           

    Chain AUTO_OUTPUT (1 references)
    target     prot opt source               destination         

    Chain AUTO_POST (1 references)
    target     prot opt source               destination         

    Chain AUTO_PRE (1 references)
    target     prot opt source               destination         
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spts:1024:65535 dpt:4444 ADDRTYPE match dst-type LOCAL

    Chain LOAD_BALANCING (1 references)
    target     prot opt source               destination         

    Chain USR_OUTPUT (1 references)
    target     prot opt source               destination         

    Chain USR_POST (1 references)
    target     prot opt source               destination         
    MASQUERADE  all  --  192.168.23.0/24      0.0.0.0/0            policy match dir out pol none

    Chain USR_PRE (1 references)
    target     prot opt source               destination         
    gate:/home/login #

    --Johannes
  • 0
    At least you have a masquerading rule, so there's still hope. =)

    I have more questions now:
    What networks are connected by the SSL VPN site-to-site connection?
    With which src address does the SSH packet come in on the internal interface?

    Edit: never mind about the networks, the log tells me it's 192.168.23.0/24 → 10.2.120.0/24
  • 0
    hi,

    yes you're right, masquerading is also nat. :-)

    home 192.168.23.0/24
    office 10.2.120.0/24

    With the src address 192.168.23.30 > 10.2.120.245 on eth0 (homeside) and
    10.242.2.6 > 10.2.120.245 on tun0 (homeside)

    --Johannes
  • 0
    Could you check if there's a matching NAT conntrack:
    conntrack -L | grep 10.2.120.245
  • 0
    gate:/home/login # conntrack -L | grep 10.2.120.245
    tcp      6 118 SYN_SENT src=192.168.23.99 dst=10.2.120.245 sport=39754 dport=22 packets=2 bytes=120 [UNREPLIED] src=10.2.120.245 dst=10.242.2.6 sport=22 dport=39754 packets=0 bytes=0 mark=0 use=1
    conntrack v1.4.0 (conntrack-tools): 101 flow entries have been shown.
  • 0
    There. Could you try if the problem (and NAT conntrack) is gone when you disable the masquerading rule?
  • 0
    I have disabled the masquerading rule, and it works.

    tcp      6 86358 ESTABLISHED src=192.168.23.99 dst=10.2.120.245 sport=40095 dport=22 packets=15 bytes=2489 src=10.2.120.245 dst=192.168.23.99 sport=22 dport=40095 packets=15 bytes=3009 [ASSURED] mark=0 use=1
  • 0
    Back from consulting with a colleague. A mdw bug is causing this. The masq rule is missing the interface information, so the kernel picks a nice looking interface itself; your tun0. Will open an ID for this right away.

    Thanks for taking the time drilling this down. Much appreciated!
Unfiltered HTML