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

VPN User DMZ Access Question

I have a VPN user (authenticating via the Astaro SSL client) who I wish to give full access to all services on my DMZ (10.0.0.x)

He needs to FTP, SFTP, SSH, HTTP, HTTPS, etc. so I'd rather just give him trusted access to all services within the DMZ only.

How would I do this?

My DMZ network: 10.0.0.x
VPN user receives an IP of: 10.242.2.6
My LAN (not DMZ): 192.x.x.x

Assuming that he will only have FTP, SFTP, SSH, etc. access when LOGGED-IN (not externally), I guess a Packet Filter rule (no DNAT rule) is all I need?

Some guidance is much appreciated! Thanks


This thread was automatically locked due to age.
  • Maybe I'll answer my question here, how about this Packet Filter rule:

    Source: VPN Pool (SSL)
    Service: Any
    Destination: DMZ (Network)
    Action: Allow


    That should do it, no?
  • The "standard" approach would be to add "DMZ (Network)" to 'Local networks' in the SSL Remote Access configuration.  If it's there already, then there's a different problem.

    Cheers - Bob
  • As Bob said, adding the DMZ to the allowed networks (and selecting automatic packet filter rules) is the common approach.  To limit access, you would need packet filter rules like those you listed, and make sure the "automatic packet filter rules" checkbox is not checked.
  • Hey guys,

    I have the "DMZ (Network)" added to the 'Local networks' within the SSL Remote Access page.

    I also have that particular user added above in the 'Users and groups' section as well.

    I actually had to create a DNAT rule to allow the SSL VPN Pool to access a service on my DMZ host (SSH). I don't get it?

    DNAT rule in order to access SSH on an Internal  Host (in the DMZ):
    Traffic Source: VPN Pool (SSL)
    Traffic Service: SSH
    Traffic Destination: Host 1 (DMZ, defined)
    NAT Mode: DNAT
    Destination: Host 1 (DMZ, defined)


    ONLY now can the user access that particular HOST via SSH... I have to create a separate DNAT rule for EACH host and EACH service apparently.

    Something's not right???
  • Instead of DNAT, try a Masquerade rule, SSL VPN pool to the DMZ interface.
  • Hi Jack, why would either DNAT or Masq be needed?

    Dakrisht, you have 'auto packet filter' on the VPN, or you've got this rule enabled, right?

    Source: VPN Pool (SSL)
    Service: Any
    Destination: DMZ (Network)
    Action: Allow

    The IPs of your VPN pool don't conflict with your DMZ, right?

    Barry
  • Hey guys,

    I too was wondering why I need NAT rules for every service to EVERY host???

    Originally, I tried a packet filter rule to allow the VPN Pool (SSL) -- [SSH Service] --> DMZ (Network).

    Didn't work.

    My understanding of network security also tells me that a simple Packet Filter rule such as this: VPN Pool (SSL) -- [ANY] --> DMZ (Network) would allow ANY service to be accessed in the DMZ from the VPN SSL Pool.

    Also didn't work.

    My DMZ is 10.0.0.x and my VPN (SSL) Pool is 10.242.2.x - so no they don't.

    Barry, I do indeed have "Auto packet filter" checked under the SSL settings...
  • Hi Barry, I was afraid someone would ask that.  I have found that sometimes VPN traffic only works reliably when it is NAT'd into the local segment.  Sometimes it is because of network configuration on the internal segment, but sometimes it seems to defy logic (but it works).
  • Even my Internal (Network) can't access SSH on the DMZ network - packets are being dropped.

    Getting a little frustrating! [H]

    I have a Packet Filter rule setup in position 7:

    Internal (Network) -- ANY --> DMZ (Network)

    Packet Filter log still shows 192.168.0.x (local machine) --> 10.0.0.1:22 being dropped.

    I don't get it - again.

    (((also tried a Masquerade rule Internal (Network) --> DMZ (Network) to no avail)))
  • I bet you have network or host definitions bound to specific interfaces.  That will screw up all kinds of routing.

    If that's not it, I'm stumped.