Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 4 subscribers
  • Views 14875 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

SSL VPN Connects but can't ping inside network

RobertBarbrow

I had my utm 120 die earlier this week. I have replaced it with a SG 210 but i didn't want to move the backup because of some gremlins in the config of the utm 120 i didn't want to transfer over

I've setup a ssl vpn for all ad authenticated users the local networks are set to internal (network) with automatic firewall rules checked and I can connect on port 443

The client connects with no problem and gives me an ip of 10.10.11.6 (internal network is 10.10.10.x) I can ping the router (10.10.10.1) but i can not ping any servers in my internal network.

I checked the firewall live log and I don't see any packets (ping or rdp) being droped by the vpn client

I am racking my brain trying to figure out why this identical config works on the old utm but not the new one. Clearly i've missed something any suggestions on what to check?



This thread was automatically locked due to age.
Parents
  • 0

    Robert, I'm a big believer in matching the "culture" of a community, so the first thing I would do would be to restore the VPN Pool to its default 10.242.2.0/24 if that doesn't conflict with other settings or corporate policy.

    It's obviously a routing problem and Emile's suggestion of an SNAT or a masq rule is the perfect quick-n-easy fix.  I would want to know the reason for the problem,  Do the internal servers all have the UTM as their default gateway?  Do the internal servers have a subnet mask that overlaps 10.10.11.0/24?  Have you accidentally connected two interfaces into the same Ethernet segment?  See #3.1 in Rulz.

    Cheers - Bob

Reply
  • 0

    Robert, I'm a big believer in matching the "culture" of a community, so the first thing I would do would be to restore the VPN Pool to its default 10.242.2.0/24 if that doesn't conflict with other settings or corporate policy.

    It's obviously a routing problem and Emile's suggestion of an SNAT or a masq rule is the perfect quick-n-easy fix.  I would want to know the reason for the problem,  Do the internal servers all have the UTM as their default gateway?  Do the internal servers have a subnet mask that overlaps 10.10.11.0/24?  Have you accidentally connected two interfaces into the same Ethernet segment?  See #3.1 in Rulz.

    Cheers - Bob

Children
No Data