SSL VPN on all IP

Hi, Andi, and welcome to the User BB!

1. I never tried that.  I would think that would cause the internal user to be unable to access any resources on the same, internal network.  Are you certain this is happening?  What do you want to to do that isn't possible now?

2. I assume you mean that you want to DNAT incoming HTTPS traffic to a certain internal IP?  Just put an 'Additional Address' ('Network >> Interfaces') on the External interface, and use that for your DNAT.  You will want to leave port 443 unencumbered on the primary address so that you don't disrupt User Portal access.

3. SSL VPN Remote Access has two-factor authentication, certificate and username/password, so it's very secure.  I think it's possible to use DNATs to keep specific traffic and drop all the rest, but I haven't tried it with the SSL VPN.  Are you certain this is a problem you need to address?

Cheers - Bob

Hi Bob :-)
Thank for your reply.

To my surprise the VPN server can be reached via LAN-IP too. I don't want that.
How can i block this access and use those port on the Interfaces/IPs for other purposes?


1. I never tried that.  I would think that would cause the internal user to be unable to access any resources on the same, internal network.  Are you certain this is happening?  What do you want to to do that isn't possible now?

Currently (without VPN) the users in the (internal) LAN have only access to the (extra)proxy in the LAN and a HTTPS Intranet-Server in a DMZ and are allowed to do DNS and Ping.  
The Astaro serves as default gateway for the LAN.
The LAN addresses are natted and one Astaro interface is "open" to the LAN for routing to Internet and DMZs.
I think i wasn't clear,  here is an example:
Say from 10.10.10.10/24 (LAN) in can open the VPN using 10.10.10.1/24 (Astaro Gateway) and (!) on ***.***.***.1/28 (IP in the Internet)
I noticed that the user lost connectivty when i open the VPN from one PC in the LAN (After editing the .opvn to connect to the internal IP) ...so your thought is right. It would make no sense to do that as it renders the LAN useless, but it would be possible an a script kiddy could block the entire internal networking. That's not the way i want to go. :-)
Maybe it would help if i enable the user interface on the internal LAN to block the use of 443. (i don't have it currently always running)

But i don't see a way to bind the VPN only to ***.***.***.2.
Where can i enter the adresse of the interface?
(I can enter the host name in the VPN config, but that is only used to generate the client configs.)

Second i have a HTTPS server already running on the Primary IP, but i want to use 443 TCP for SSL VPN because this makes it easier to get thru firewalls/proxies.
How can i bind the VPN server to a specific IP alias?

2. I assume you mean that you want to DNAT incoming HTTPS traffic to a certain 
internal IP? 

 

Yes.
I have a HTTPS server already running in the DMZ on 10.20.20.2/24
That HTTPS is Dnatted to (from?)  ***.***.***.1/28:433, which is 
the "primary" (main) IP
Now i want to have the VPN on ***.***.***.2:443alias to preserve .1:443  for historical reasons.

But, if i understood the discussion in the web right, VPN can only bind 
to the primary "main" IP of an interface (***.***.***.1/28)so it is not possible 
to "bind" it to(from?) ***.***.***.2/28:443
Or is that information obsolete?
(if in write "bind" i meant mostly "Dnat")

Just put an 'Additional Address' ('Network >> Interfaces') on the External interface, and use that for your DNAT.  

Did that, but where do i find the other end of the Dnatting rule?
Another effect:
After adding that alias address (without activating it with Dnat) i found that i after a open port 25 on that address too.
The SMTP proxy of the astaro seems to listen on all interfaces too if i don't define a blocking rule...

You will want to leave port 443 unencumbered on the primary address so that you don't disrupt User Portal access.

But that ***.***.***.1:443 is already in use by the clients outside. :-(
I can't change that anymore. (someone long time ago someone found it 
superflux to define a CName/ALias PTR record in the DNS and uses the 
IP or our mail-DNS name for the Clients. I know: Outch.)

3. SSL VPN Remote Access has two-factor authentication, certificate and username/password, so it's very secure. 

If someone steals or (worse as none would have  noticed) copies the 
Notebook's Certificates (which are not very good protected in openVPN) 
and the password is weak or written somewhere...i would sleep better when i know that no third party could connect from any IP . Too it would keep brute force breaking attemps low. 
I know i'm paranoid :-)
I would like have one time passwords (secure token or so)
and maybe "page knocking" to hide/reuse the port too :-)

 I think it's possible to use DNATs to keep specific traffic and drop all the rest, but I haven't tried it with the SSL VPN.  Are you certain this is a problem you need to address?

Did i mention i'm paranoid ? :-))

Dnattig is a nice idea, but:
Where do i find those internal server definitions to name them in the Dnatting rule?
I can Dnat the IP of the "user IP" used in VPN. But the VPN server himself? 
I can't even bind it to a single specific IP. I assume it binds to all existing /dev/eth (and no etnX.y)?
Maybe i am missing a point? (or two?) :-)


Thanks again for your good questions!
Maybe you find time to make good questions further?

The Remote Access servers not based on IPsec cannot be bound to an interface.  If you really want to block connection internally with the SSL VPN, then I think I'd choose a different port than 443 ('Settings' tab), as blocking that would block all HTTPS traffic.  Then, in order to block that traffic, instead of a packet filter rule, DNAT the traffic to a non-existent IP, like:

Traffic Source: Internal (Network)
Traffic Service: {new service definition instead of HTTPS}
Traffic Destination: Internal (Address)

NAT mode: DNAT (Destination)

Destination: {a non-existent IP}
Destination Service: {leave blank!}

You can do a similar rule for the External IPs, null-routing traffic to  ***.***.***.1/28 that's not supposed to pass.  DNATs are considered in order, so you should be able to make a rule above it like '{specific IPs} -> {SSL VPN port} -> {***.***.***.2} : DNAT to {SSL VPN port}' to allow the passage of traffic from "specific IPs" to establish the VPN.  Once the VPN is established, the traffic will come from "VPN Pool (SSL)", so these DNATs won't have any affect.

The basic rule for traffic arriving at an interface is: DNATs are considered first, then Proxies, and, finally, manual Routes and Packet Filter rules.  I think VPNs are considered after DNATs and before Proxies.

Your DNAT for inbound traffic to your internal server should look like:

Traffic Source: Internet
Traffic Service: HTTPS
Traffic Destination: External (Address) [{name of additional address}]

NAT mode: DNAT (Destination)

Destination: {Host defnition for internal server}
Destination Service: {leave blank!}

Check out Astaro Gateway Feature Requests - you can vote for one-time passwords and page-knocking capabilities.

Cheers - Bob

The Remote Access servers not based on IPsec cannot be bound to an interface. 

Thanks. That's clear.  Where should i have read this? :-)

(My curiosity lets me ask: Why does this happen? :-))

 If you really want to block connection internally with the SSL VPN,

I want to have the Astator User Interface on the LAN.1:443.
I already have OMA on External.1:443
I want to have our main https server on external.3
It would be nice to have VPN on External.4:443 (OK is not a must as our roadwarriors have UMTS and will never connect to forign nets but...)
I want to have Astaro User Interface on External.5:443
I want to have SMTP-Proxy on Exernal.1:25,:465,:585(?) but NOT on External.2 and .3 and .4 and .5....
The :443 on the alias would be no problem as long as the server is "outside" astaro, right?
But Astaros internal severs can't neither be DNATed or be directed thru paket filtern and always bind to all aliases of the interface?

Because i have to be able to run several different HTTPS servers i have  more than one IP. That would work using aliases and DNAT.  OK.
But on every alias IP the astaro smtp server would occure, right? 

Do i understand right:
if i want my External IPs/Aliases not been "littered" with superflous mirrors/shadows of the internal astaro servers like SMTP-proxy i have to define for every IP-alias dummy rules? If i have a full /25 in use for :443 i have to define 126 dummy rules for :25 instead of telling the exim(e.g.) just to bind the one IP where it is wanted?
I think i must have missunderstand something or is astaro not intended to be used in such environment and i need dedicated router/paketfilter/(D)NAT-only device in front of astaro or a second astaro just for those services?
If i could define a DNAT rule to the astaro internal SMTP server(e.g.), i could add a second DNAT for the "remaining entire" net to a dummy, not existing server, right?

Check out Astaro Gateway Feature Requests - you can vote for one-time passwords and page-knocking capabilities.

Thanks for the hint!

If i could define a DNAT rule to the astaro internal SMTP server(e.g.), i could add a second DNAT for the "remaining entire" net to a dummy, not existing server, right?

Yes, I think you can accomplish your goal for SMTP with two rules similar to the ones I suggested for SSL:

You can do a similar rule for the External IPs, null-routing traffic to ***.***.***.1/28 that's not supposed to pass. DNATs are considered in order, so you should be able to make a rule above it like '{specific IPs} -> {SSL VPN port} -> {***.***.***.2} : DNAT to {SSL VPN port}' to allow the passage of traffic from "specific IPs" to establish the VPN.

I haven't done that before, so please let us know if that works!

Cheers - Bob
PS if you're using Web Application Security, you don't need a DNAT to send traffic to your internal webserver.  Similarly, if you're using Mail Security, you don't want a DNAT to direct traffic to your mail server.  The basic rule for traffic arriving at an interface is: DNATs first, then Proxies, and finally, manual Packet Filter and Routing rules.

PS if you're using Web Application Security, you don't need a DNAT to send traffic to your internal webserver.  Similarly, 
if you're using Mail Security, you don't want a DNAT to direct traffic to your mail server.  
The basic rule for traffic arriving at an interface is: 
DNATs first,  then 
Proxies, and finally, manual 
Packet Filter and 
Routing rules.

a) Web Security is currently not licenced as the outside user are "well known" so the servers should not be public avaiable (Therefor my wish to limit the access IP)
b) I think that does not look professional if the one an only SMTP server occures on every alias i activate. So i want to "earthen" the unused, duplicated port 25.
(In SMTP servers i sat up i bound the server to explict IPs, not the entire interface (127.0.0.1 plus WAN IP plus LAN IP). 

My big question is how can i get this with one astoro:
WAN.1:443 -> DNATed HTTPS server (TCP wrapped access only from dedicated networks)
WAN.2:443 -> Astaro User Interface
WAN.3:443 -> SSL VPN(OpenVPN) (You said that this is impossible with astaro IIRC, i have to use UDP or an other port on WAN.1,say :565 e.g.)

So i must end up 
First attempt:
WAN.1:443 -> SSL VPN
WAN.2:443 -> DNATed HTTPS server
WAN.3:443 -> Astaro User Interface (does not work as the User interface is bound to an interface, not an IP.)

Final attempt:
WAN.1:210 -> SSL VPN
WAN.1:443 -> Astaro User Interface
WAN.2:443 -> DNATed HTTPS server


I don't see under "network definition" any names for services offerd by the astaro.
So i don't know how i could "bind" those services to a dedicated IP(Alias).

Is there a way like binding internal services first to a (named) virtual interface
or so?