SSL VPN on all IP

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.  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!