Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 5365 views
  • Users 0 members are here
Options
Suggested
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

Pushing routes

stevecharon
Hi, 
I have a running SSLVPN on my ASG320 with 7.306.
We recently changed our IP scheme and introduced VLAN in our Network.
Internally everything works like a charm.
We are using networks starting with 10.46.x.x on a /21 subnet =255.255.248.0
So I added 10.46.16.0/21, 10.46.24.0/21 and 10.46.32.0/21 to all the places for our SSL-VPN-users.
And the clients gets the routes pushed successfully for every net but the 10.46.16.0.
There I see the net 10.46.16.0/20 gets pushed.
Resetting the network definitions, deleting and recreating the allowed nets for SSLVPN to no avail.
Since there are our servers in 10.46.16.0/21 - no SSLVPN-user can access them.

Any clues around?


This thread was automatically locked due to age.
Parents
  • 0
    Check the client config files and see if the routes are correct in there.
    Or try re-creating them if you haven't already.

    Barry
  • 0 in reply to BarryG
    What subnet is the 'SSL VPN (Pool)'?
  • 0 in reply to BAlfson
    @BAlfson
    Sorry, the subnet was changed to 10.46.40.0/21.
    @BarryG
    Sorry, no routes inside my client-ovpn. As expected since they are been pushed from the ASG to the client during connect.
  • 0 in reply to stevecharon
    Steve, have you looked at the packet filter logs to be sure the packets aren't being blocked there?  Have you tried removing the VPN installation from a client and then re-installing?

    Still, it doesn't make sense that you define a subnet as /21, but the Astaro pushes /20.  Barry, is there a way for Steve to see the information in the Astaro that should be pushed?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi BAlfson,
    the packets are not blocked, since I see that Astaro pushes net 10.46.16.0/20 successfully. However, this net does not exist in our environment.
    Though I havent tried to look for the definition thru ssh.
    Do you know where I have to go for this information?
    The VPN installation is currently up and running on 100 laptops out there. 30 % rolled out after I had reset the 16.0/21 network definition. I also deleted the definition an recreated it.
    Sure it doesnot make sense but I have to confess this is the truth.

    Best regards

    steve
  • 0 in reply to BAlfson
    Still, it doesn't make sense that you define a subnet as /21, but the Astaro pushes /20.  Barry, is there a way for Steve to see the information in the Astaro that should be pushed?


    I thought that the routes would have been in the client files, but they're not. Sorry.

    Barry
  • 0 in reply to BarryG
    Hi,

    I looked thru ssh seeing that the routes there are correct.
    The 10.46.16.0/21 is shown as expected.
    But my clients still get 10.46.16.0/20 pushed.
    I grepped thru the files in the chrooted env for 255.255.240.0 to no avail.

    I also used the native openvpn client 2.1_rc15 with no difference.
  • 0 in reply to stevecharon
    client

    dev tun

    proto tcp

    remote x.x.x.x 443

    tls-remote "/C=de/L=***x/O=******xx/CN=******x/emailAddress=***************************@*********xx.net"

    resolv-retry infinite

    nobind

    persist-key
    persist-tun

    ca x.x.x.x.ca.crt
    cert x.x.x.x.user.crt
    key x.x.x.x.user.key

    auth-user-pass

    cipher AES-256-CBC
    auth MD5

    comp-lzo

    verb 3

    reneg-sec 0
  • 0 in reply to stevecharon
    Steve, I just reread this thread.  I don't understand why the users can't see all of 10.46.16.0/21 if they have a route for 10.46.16.0/20 as that includes 10.46.16.0/21.  I would understand if there were attempts to reach 10.46.24.0/21 because the remote users would have routes to two different VLANs.

    So, here is a SWAG...  What if the definition of your VLAN is in error and is 10.46.16.0/20?  If that's where your servers are and they are all assigned fixed IP addresses, then you haven't got anything in there that has a 10.46.24.0/21 IP, so you aren't experiencing any conflicts locally.

    In the future, rather than creating network definitions for your VPN definitions, just use the networks created by the Astaro when you configure the interfaces; 'Internal (Network)' as an example.

    Is that it?

    Cheers - Bob
  • 0 in reply to BAlfson
    I don't understand why the users can't see all of 10.46.16.0/21 if they have a route for 10.46.16.0/20 as that includes 10.46.16.0/21.  I would understand if there were attempts to reach 10.46.24.0/21 because the remote users would have routes to two different VLANs.

    This is because if I activate the 10.46.16-route the 10.46.24-route is no longer pushed caused by the overlapping subnets that rises through the false /20 subnet (which includes the 10.46.24/21)
    Then the 10.46.16/21 is accessible, but I then have trouble to reach the 10.46.24/21

    So, here is a SWAG...  What if the definition of your VLAN is in error and is 10.46.16.0/20?  If that's where your servers are and they are all assigned fixed IP addresses, then you haven't got anything in there that has a 10.46.24.0/21 IP, so you aren't experiencing any conflicts locally.

    No, I rechecked the definitions, even thru shell access. It is definitely 10.46.16.0/21 written to the openvpn-server-config but pushed is 10.46.16.0/20.
  • 0 in reply to stevecharon
    I think it's time for Astaro Support to take a look.

    Cheers - Bob
Reply Children
No Data