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

VPN (SSL) cannot access WebServer on DMZ

edwardl.a.u
Hi Everyone,

I am having trouble accessing our webserver when remote on VPN (SSL). 
I can RDP, FTP, ping etc. the webserver in the office with no problem. 
From other threads I understand that its only required to add the DMZ of 
the webserver to the local networks but unfortunately this is not enough 
in my case. The packets seem to get to the VPN SSL interface then gets lost.

The details are as follows:

Our network interfaces are:

Internal on eth0 [172.17.10.1/16]
External on eth1 [192.168.2.101/24]
WebServer on eth1 [10.157.89.1/30]

Network Definitions:
External (WAN) Address 192.168.2.101
External (WAN) Network 19.2168.2.0/24
Internal Address 172.17.10.1
Internal Network 172.17.0.0/16
Webserver Address (interface) 10.157.89.1
Webserver Network 10.157.89.0/30
Webserver (Bound to Webserver) 10.157.89.2
VPN Pool (SSL) 10.242.2.0/24

DNAT:

1. Full NAT [Webserver]
Traffic selector: Any -> FTP -> External (WAN) Address
Source translation: External (WAN) Address
Destination translation: WebServer
Automatic packet filer rule: X

2. DNAT [Webserver]
Traffic selector: Any -> FTP -> External (WAN) Address
Source translation: External (WAN) Address
Destination translation: WebServer
Automatic packet filer rule: X

3. Full NAT [Webserver]
Traffic selector: Any -> HTTP -> External (WAN) Address
Source translation: External (WAN) Address
Destination translation: WebServer
Automatic packet filer rule: X

2. DNAT [Webserver]
Traffic selector: Any -> HTTP -> External (WAN) Address
Source translation: External (WAN) Address
Destination translation: WebServer
Automatic packet filer rule: X

Packet Filter:

Internal (Network) -> WebServer : RDP - Allowed
Internal (Network) -> WebServer : HTTP - Allowed
Internal (Network) -> WebServer : FTP - Allowed
Internal (Network) -> WebServer : DNS - Allowed
Internal (Network) -> WebServer : Any - Drop

Remote Access:

SSL -> Local Networks: Internal (Network) + Webserver (Network)
Automatic packet filter rules  ticked

Routes are added correctly on client side: 
C:\>Route print yields
Dest 10.157.89.0 Mask 255.255.255.252 Gateway 10.242.2.45 Interface 10.242.2.46
+ others...

Trace Route:

C:\>tracert 10.157.89.2
1. * 4ms 6ms 10.242.2.1
2. *  *   *  Request timed out.
3. *  *   *  Request timed out.

Netcat listening to any ports failed

only PF log drop is:
dropped UDP 10.242.2.46:137 -> 10.242.2.1:137

Am I missing something? would appreciate any suggestions.

Cheers,
Eddie


This thread was automatically locked due to age.
Parents
  • 0
    If you're VPN'd in, you shouldn't need the last DNAT.  It's only real purpose here was to allow packets to pass.  All you should need is a packet filter rule like 'VPN Pool (SSL) -> Web Surfing -> Webserver (Network) : Allow'.

    Also, when you bind a definition to a particular interface, using that definition in a DNAT can cause random issues.  Trying to reach it via VPN also can be a problem.  I suggest you set interface to > in all of your manually-created host/network definitions unless Astaro Support specifically has told you to change one to be bound to a particular interface.

    The Full NATs only offer an advantage in your situation when not using the HTTP/S Proxy, and you want to reach an internal webserver via the IP listed in its public FQDN.

    Once you get the hang of the Astaro, it's all very intuitive.

    Cheers - Bob
    PS Not sure about the ARP request issue, but it seems normal that a device would broadcast an ARP request to everything local for an IP in its subnet for which it has no MAC address.  In fact, I think in recent versions of Astaro, they must have "fixed" it so that it answers ARP requests for VPN IPs that are in the subnet of  a local network (which is not your case).
Reply
  • 0
    If you're VPN'd in, you shouldn't need the last DNAT.  It's only real purpose here was to allow packets to pass.  All you should need is a packet filter rule like 'VPN Pool (SSL) -> Web Surfing -> Webserver (Network) : Allow'.

    Also, when you bind a definition to a particular interface, using that definition in a DNAT can cause random issues.  Trying to reach it via VPN also can be a problem.  I suggest you set interface to > in all of your manually-created host/network definitions unless Astaro Support specifically has told you to change one to be bound to a particular interface.

    The Full NATs only offer an advantage in your situation when not using the HTTP/S Proxy, and you want to reach an internal webserver via the IP listed in its public FQDN.

    Once you get the hang of the Astaro, it's all very intuitive.

    Cheers - Bob
    PS Not sure about the ARP request issue, but it seems normal that a device would broadcast an ARP request to everything local for an IP in its subnet for which it has no MAC address.  In fact, I think in recent versions of Astaro, they must have "fixed" it so that it answers ARP requests for VPN IPs that are in the subnet of  a local network (which is not your case).
Children
No Data