Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN UTM <-> dd-wrt partially working...

Hey,

I have a problem.
I've Connected my home UTM with a DD-WRT owned by my brother. (SSL VPN)

I have the address range:
192.168.0.1 - 192.168.3.254
subnet 255.255.252.0

My brother has the address range
192.168.4.1 - 192.168.4.254
subnet 255.255.255.0

I followed the following instructions:
Insatiable Ramblings | Astaro Site to Site VPN with DD-WRT

This does work,  partially ... : (

My brother is coming into my network, but I can not get into his.

I'm assuming the DD-WRT has be set the routes correctly.
My UTM does not...

How do I fix this?

I thank you,
Ciao


This thread was automatically locked due to age.
  • Hi, have you defined your LAN network in the DD-WRT VPN?

    Have you defined your brother's network in the Astaro VPN?
    Did you add a packetfilter rule to allow your outbound traffic?

    Might help if you post screenshots of all the configs.

    Barry
  • Are you sure about:

    192.168.0.1 - 192.168.3.254
    subnet 255.255.252.0
    ?

    The netmask doesn't jibe with the address range.
  • Are you sure about:

    ?

    The netmask doesn't jibe with the address range.


    it does....


    netmask = 255.255.252.0
    host min =192.168.0.1
    host max = 192.168.3.254
    /22 net 

    Tomorrow i post my cfg.which part of the config you need?
  • 'Edit SSL Connection' in the UTM and the corresponding config from the other side.

    Cheers - Bob
  • My bad.  Had 255.255.255.252 on the brain.  Didn't read close enough.  long day.
  • Hi,

    Config of my UTM.



    Internal Network is 192.168.0.0/22
    Site B is 192.168.4.0/24


    config(and autostart) for dd-wrt is:
    sleep 30
    echo “REF_uClaMWVnny
    REF_VMHOQOXAGW0000ref_vmhoqoxagw” > /tmp/openvpncl/user.conf
    sleep 10
    echo “client
    dev tun
    proto udp
    hand-window 30
    port 1195
    remote REMOTE SERVER
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca /tmp/openvpncl/ca.crt
    cert /tmp/openvpncl/client.crt
    key /tmp/openvpncl/client.key
    cipher BF-CBC
    auth SHA1
    comp-lzo
    route-delay 4
    verb 3
    reneg-sec 0
    auth-user-pass /tmp/openvpncl/user.conf” > /tmp/openvpncl/vpn.conf
    ( sleep 10 ; killall openvpn ; /usr/sbin/openvpn –config /tmp/openvpncl/vpn.conf –auth-user-pass /tmp/openvpncl/user.conf –route-up /tmp/openvpncl/route-up.sh –down /tmp/openvpncl/route-down.sh –daemon ) &



    any idea? 

    Daniel

    Edit#1:

    And here is my Tunnel status from my UTM
  • A belated welcome to the User BB, Daniel!

    (I assume that you have allowed pinging, etc. on the 'Firewall' 'ICMP' tab if this is how you're testing your connection.)

    Is there anything in the Intrusion Prevention log - UDP Flood Protection maybe?  How about the Firewall log?  If there's nothing to be changed in either of those, it's time to look at the SSL VPN log for one connection attempt.

    Cheers- Bob
  • A belated welcome to the User BB, Daniel!

    (I assume that you have allowed pinging, etc. on the 'Firewall' 'ICMP' tab if this is how you're testing your connection.)

    Is there anything in the Intrusion Prevention log - UDP Flood Protection maybe?  How about the Firewall log?  If there's nothing to be changed in either of those, it's time to look at the SSL VPN log for one connection attempt.

    Cheers- Bob


    Hey,
    The Firewall, Intrusion Prevention is completely empty about vpn.

    The SSL-VPN log says :

    2012:09:10-14:32:55 utm openvpn[28516]:  TUN READ [1408]
    
    2012:09:10-14:32:55 utm openvpn[28516]: UDPv4 WRITE [1445] to *.*.*.*:58695 (via *.*.*.*): P_DATA_V1 kid=0 DATA len=1444
    2012:09:10-14:32:55 utm openvpn[28516]:  TUN READ [1408]


    an so on... What the *uck did i make wrong?
    I'm totally disoriented... Please help.. :/
  • Oops!  I just noticed that the DD-WRT has port 1195 instead of 1194.  Does it work if you change that?

    If not, then we need to see the complete log lines from both sides for the same, single connection attempt.

    Cheers - Bob