I have configured OpenVPN and everything works just fine to connect. I have forced that all traffic should be routed through the VPN tunnel and I have problems to browse the internet and access anything on the green interface except the IP address of the GW.
Is there anything else that needs to be configured because I’m still a litte new to Shorewall and I have trouble to find any logs to check for any blocked ports from the dashboard? I suppose i have to grep for ports in iptable but want to check if anyone has a quick solution on this.
You should check /var/log/firewall.log.
If you’re familiar with iptables, shorewall show should give a clear picture.
You could even paste it here for us to have a look.
Thank you this helped I can see that no traffic is passing through the firewall because the DNS server is not resolving IP addresses over the VPN network. The default DNS server for openvpn is the GW and it answers to ping but not on DNS. Is there a special settings for DNS?
I’ve seen the same behaviour recently, but I couldn’t debug it. I didn’t find logs, I used tcpdump to sniff traffic and I saw an imcp destination unreachable to port 53/udp. I suspect that dnsmasq drops requests.
I found this sentence in the manual:
This option has been patched to always use SO_BINDTODEVICE socket option when binding to interfaces. As
consequence, dnsmasq WILL NOT ANSWER to any DNS Queries that come to the socket with the correct desti-
nation IP address, but originally on different interface. This behavior differs from the original dns-
masq upstream version and is used for security reasons.
I know I had the same problem in Zentyal server and we had to create a stub setting to override dns interfaces acl trusted sites. I really can’t find my notes regarding this fix.
@filippo_carletti I found the settings I used to override the DNS configuration file to get the resolution to work in the VPN network. But when I read the DNS section of the developer guide it still doesn’t make sense what files are in use for the DNS server?
// ----------------------------------------------------------------------------
//
// Instructions for /etc/dnsextd.conf (this file)
//
// In most cases, you should not need to change these default options in
// the “options” section below. The dnsextd daemon will receive DNS packets
// on port 53, and forward them on as appropriate to BIND on localhost:5030.
//
// You need to edit the “zone” statement below to give the name of your
// dynamic zone that will be accepting Wide-Area Bonjour DNS updates.
//
// ----------------------------------------------------------------------------
//
// Instructions for /etc/named.conf
//
// In /etc/named.conf you will need to modify the “options” section to
// tell BIND to accept packets from localhost:5030, like this:
//
// listen-on port 5030 { 127.0.0.1; };
//
// You also need a “zone” statement in /etc/named.conf to tell BIND the update
// policy for your dynamic zone. For example, within a small closed private
// network, you might allow anyone to perform updates. To do that, you just
// permit any and all updates coming from dnsextd on the same machine:
//
// zone “my-dynamic-subdomain.company.com.”
// { type master; file “db.xxx”; allow-update { 127.0.0.1; }; };
//
// On a machine connected to the Internet or other large open network,
// you’ll want to limit updates to only users with keys. For example,
// you could choose to allow anyone with a DNS key on your server to
// perform updates in your dynamic zone, like this:
//
// key keyname. { algorithm hmac-md5; secret “abcdefghijklmnopqrstuv==”; };
// zone “my-dynamic-subdomain.company.com.” in
// {
// type master;
// file “db.my-dynamic-subdomain.company.com”;
// update-policy { grant * wildcard *.my-dynamic-subdomain.company.com.; };
// };
//
// You could use a single key which you give to all authorized users, but
// it is better (though more work) to create a unique key for each user.
//
// ----------------------------------------------------------------------------
options {
// This defaults to: * port 53
// listen-on port 53 { 192.168.2.10; 127.0.0.1; };
// This defaults to: 127.0.0.1:5030
// nameserver address 127.0.0.1 port 5030;
// This defaults to: 5533
// private port 5533;
// This defaults to: 5352
// llq port 5352;
};
It referes to neamed.conf and bind but I couldn’t find those in the default location and got a bit insecure. Is there anyone who shortly can explain how DNS is setup in Nethserver?
What I want to achieve is to add the vpn network to the Trusted ACL location in named.conf or something similar to that in Nethserver:
NethServer’s DNS server is dnsmasq. In its manual you’ll find the note I quoted above. I’ll do more tests in the weekend and I’ll let you know my findings.
I’m sorry if I wasn’t clear anough. I saw that the DNS on Nethserver was dnsmasq but what I didn’t find was a configuration file in the default location /etc/dnsmasq.conf
I usually work with bind so this is a bit new to me and I wondered if someone could point out how DNS was setup on the server.
I just made two openvpn connections to the same nethserver and name resolution worked flawlessly in both tests.
My /etc/dnsmasq.conf is there and it’s no options related to the vpn.
I think that dns over openvpn works out of the box.
I feel bad now! I was working on a terminal session and didn’t see that the session had closed when i troubleshooted the connection and it was my local system that i referred to when I mentioned that I couldn’t find the files. That makes sense that the configuration files didn’t exist.
Just for my reference did you choose the same settings as I have listed originally to route all traffic through the DNS session and most importantly were you able to browse the internet?
Everything seems to work now … I have to do some more tests what fixet it? I recall making 3 changes were the first one was to activate DHCP scoop on eth1, the second one was remove 2 rules “any to internet on port 80,443” and the last change was to change back to allow any connection from internal to internet from blocking it as default.
Seems that something here makes the DNS to break when you try to access the internet from VPN.
Before I dig to deep into this problem. Can anyone please confirm that the below scenario should work out of the box on Nethserver?
I want all traffic to be routed to nethserver via VPN the old fashion way and therefore I need to be able to resolve all local host when connected that means green,blue,orange and red. What I don’t understand is if dnsmasq is used for dns in this scenario because the dhcp is not used for assigning vpn nwtworks nor the dns dns adress?
Example:
green = 192.168.100.x/24 DNS: nethserver
VPN = 192.168.199.x/24 DNS: 192.168.199.1 #Where is VPN DNS/DHCP handled?
Reading the documentation I found this:
NethServer can be configured as DNS (Domain Name System) server inside the network.
A DNS server is responsible for the resolution of domain names (eg. www.example.com)
to their corresponding numeric addresses (eg. 10.11.12.13) and vice versa. The server performs DNS name resolution requests on behalf of local clients,
and it is accessible only from the LAN network (green) and the guest’s network (blue).
During a name lookup the server will:
search for the name between hosts configured locallyperform a query on external dns: requests are stored in cache to speed up subsequent queries
If NethServer is also the DHCP server on the network, all the
machines will be configured to use the server istelf for name
resolution.
I feel bad now! I was working on a terminal session and didn’t see that the session had closed when i troubleshooted the connection and it was my local system that i referred to when I mentioned that I couldn’t find the files. That makes sense that the configuration files didn’t exist.
… I have to do some more tests what fixet it? I recall making 3 changes were the first one was to activate DHCP scoop on eth1, the second one was remove 2 rules “any to internet on port 80,443” and the last change was to change back to allow any connection from internal to internet from blocking it as default.