Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 779 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

RED VPN clients DNS problem

deltaline-IT
i have an serious problem with DNS resolving at  RED10 VPN branch which is connected to HO through astaro v8.300.  vpn tunnel is up and i can ping servers at HO by ip and FQDN (after adding masquerading rule branch1 network to internal interface). when i try to join client at branch to join  domain (which is at HO) its giving me DNS  error...  i am new to astaro and dont have much experience but i try to figure out the problem but no use.... 

branch getting DHCP from VPN pools i tried to change the dns directing to domain server at HO but not help...

waiting for some help......


This thread was automatically locked due to age.
Parents
  • 0
    I assume that the RED is not bridged to the internal network, and that it has its own subnet.  Do you have an Astaro DHCP service set up for that network?  That's necessary unless you plan on manually assigning IP addresses.  Do you have Firewall rules that allow the traffic?  I guess that you don't since only pings pass.

    If you have only a single remote office, you might want to consider bridging the RED instead.  That would simplify the configuration, and the network in the remote office would be on the same subnet, and could use the same DHCP server with the "Internal (Network)".

    Pinging and traceroute behaviors are determined by the settings on the 'ICMP' tab of 'Firewall', not by Firewall rules.

    If you are having to use a masquerading rule 'Branch1 (Network) -> Internal', then there's another configuration error.  Please check all of your definitions to be sure that none are bound to a specific interface; all should have 'Interface: >'.  Once you fix all of these, you should be able to delete the masq rule.

    Is the hostname of the Astaro a FQDN resolvable to "External (Address)" in public DNS and to "Internal (Address)"  in internal DNS?  If you didn't set it up like that in the beginning, I'd be tempted to recommend that you start over with a Factory Reset.  You can use the rest of your configuration if you first make a backup with the two following boxes checked:

    While creating the backup, remove the following data: 
     
      Host specific data, e.g. host name, certificates, ... 
      Administrative mail addresses.


     
    Also, since you mentioned DNS, you might want to consult DNS Best Practice.

    Cheers - Bob
    PS What subscriptions do you have?
Reply
  • 0
    I assume that the RED is not bridged to the internal network, and that it has its own subnet.  Do you have an Astaro DHCP service set up for that network?  That's necessary unless you plan on manually assigning IP addresses.  Do you have Firewall rules that allow the traffic?  I guess that you don't since only pings pass.

    If you have only a single remote office, you might want to consider bridging the RED instead.  That would simplify the configuration, and the network in the remote office would be on the same subnet, and could use the same DHCP server with the "Internal (Network)".

    Pinging and traceroute behaviors are determined by the settings on the 'ICMP' tab of 'Firewall', not by Firewall rules.

    If you are having to use a masquerading rule 'Branch1 (Network) -> Internal', then there's another configuration error.  Please check all of your definitions to be sure that none are bound to a specific interface; all should have 'Interface: >'.  Once you fix all of these, you should be able to delete the masq rule.

    Is the hostname of the Astaro a FQDN resolvable to "External (Address)" in public DNS and to "Internal (Address)"  in internal DNS?  If you didn't set it up like that in the beginning, I'd be tempted to recommend that you start over with a Factory Reset.  You can use the rest of your configuration if you first make a backup with the two following boxes checked:

    While creating the backup, remove the following data: 
     
      Host specific data, e.g. host name, certificates, ... 
      Administrative mail addresses.


     
    Also, since you mentioned DNS, you might want to consult DNS Best Practice.

    Cheers - Bob
    PS What subscriptions do you have?
Children
No Data