Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Different rules depending on SSLVPN user group ?

MaximeMaxime Newbie ✭
edited February 2021 in SSL VPN

Hi,

I'm trying to apply different NAT Rules to users users depending on if they are connected to SSLVPN or not and added to an user group (optionnal but would be useful).


Here is what I want to do :


#1 : If an SSLVPN user (origin = 10.10.xx.xx) added on group "my group" asked public IP 1.1.1.1 (80)

=> Redirect to private IP 2.2.2.2 (80)


#2 : If a public user (origin = any) / no group asked public IP 1.1.1.1 (80)

=> Redirect to private IP 3.3.3.3 (80)


What I did is 2 Access Rules :

#1 : From SSLVPN to DMZ - Source 10.10.xx.xx - Dest 2.2.2.2 (80) - Users Incl. "my group"

#2 : From WAN to DMZ - Source Any - Dest 3.3.3.3 (80)


And 2 NAT Policies :

#1 : Source 10.10.xx.xx - Original Dest 1.1.1.1 - Translated Dest 2.2.2.2

#2 : Source Any - Original Dest 1.1.1.1 - Translated Dest 3.3.3.3


#1 rule and NAT Policy have a lower priority number


But connected or not, everything goes through #2 rule and NAT Policy (0 packet on #1) ).

Does anyone know what I'm doing wrong ?

Category: SSL VPN
Reply

Best Answers

  • CORRECT ANSWER
    shiprasahu93shiprasahu93 Moderator
    Answer ✓

    @Maxime,

    The user group field is only present for an access rule and not the NAT policy. If the traffic is allowed per the access rule, the NAT rule is chosen as per the priority.

    Since the destination address is 1.1.1.1, whichever NAT policy is at a higher priority will get triggered.

    You are using SSLVPN, so you should have direct access to the internal addresses. You can control which internal IP is allowed for a certain user/user group based on their VPN access.

    Thanks!

    Shipra Sahu

    Technical Support Advisor, Premier Services

  • CORRECT ANSWER
    MaximeMaxime Newbie ✭
    edited February 2021 Answer ✓

    @SHIPRASAHU93,

    Thanks for the information. The problem is that it is a public IP for a website, we cannot point to a private IP.

    The idea behind all this is to check an Apache proxypass on 3.3.3.3 that redirects to 2.2.2.2 before setting the destination to 3.3.3.3.

    But it made me think about a simpler solution, I'll just do it with the windows hosts file to point to local 3.3.3.3 or assign an other public address and do the same.


    Thank you both, I think I'll be able to do what I want.

Answers

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @Maxime

    what is the pool of your SSL-VPN users, which addresses you're assigning them for their SSL-VPN session in the Device Profile? If it's not in the 10.10.xx.xx range you'll probably have your answer.

    If the NetExtender clients getting 10.10.x.x addresses assigned I would suspect it should work.

    --Michael@BWC

  • MaximeMaxime Newbie ✭

    Thanks for your answer.

    Yep, 10.10.xx.xx is the IP pool (address group) assigned to the users connected with NetExtender.

    I disconnected / reconnected NetExtender multiple times to check.

  • MaximeMaxime Newbie ✭

    Hmm, I just thought about something. Maybe 1.1.1.1 should be added to client routes on the default profile.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @Maxime

    Sure thing, 1.1.1.1 should be in the routes and of course in SSL VPN Access. Maybe a Tunnel All would be easier, depending on the number of hosts you wanna route via SSL VPN.

    --Michael@BWC

Sign In or Register to comment.