[7.385] DNS Requests dropped by Default Rule

Isn't that normal behaviour? The default packet filter rule (that is, when no rules are defined in network->packet filter) is to drop everything. There is exception for webadmin, though.

Please describe what you are trying to do and what you did. You provided too little information about your setup, sorry.

it blocks the dns requests of my ASG. i can't resolve any dns from my firewall. hope that's not default behaviour! [;)] in the pf i see the requests from my external interface are dropped.

it seems that everything my asg tries to sendout themself gets blocket by default rule. i see dropped smtp traffic, etc. i created a pf rule which allows dns and https (for my ssl site-2-site), and now dns requests work, also the ssl-vpn comes up again!

Yes, thats intended behaviour of a firewall and not a bug. You have to define what to allow. There are some services on the ASG that have an option to create the needed pf rule automatically, some others open the necessary ports when enabling the feature (IPSec VPN for example).

And always remember: an allow any any any rule in packet filter does NOT allow all traffic in all directions, it only allows all traffic thats up to be fordwarded by ASG. This excludes traffic from and to the ASG itself (eg. DNS requests originating _from_  the ASG).

I know this can be confusing as the pf table shown in webadmin does _not_ show all real rules, only the ones specifically created by the user. To really see the iptables definitions, you may use iptables-save and pipe the output into a file to look at it.

we completely missunderstood.

normaly dns requests from the dns proxy on the firewall are allowed by default. also the smtp proxy is allowed to send emails. but that doesn't work. also the communication of the site-2-site ssl vpn only works, if i allow it with an own pf rule. i hope you understand what i mean!

for further questions you can give me a call, i can send you my phone number via pm!

First, there is no DNS proxy on ASG. Its a normal DNS server with reduced functionality (You cant define zones).

Second, Site2Site VPN defenitively works when you activate the automatic packet filter rule option when activating VPN. I've already tested that today.

hi again,

the site-2-site works that's right. but it didn't establish until i created a rule which allowed ssl from external interface. before i did this i saw the pakets coming from astaro dropped in the log. if i do an iptables -L i have no rules in the AUTO_OUTPUT chain, where i normally see the rules for dns from astaro or smtp or even ssl-vpn if activated. the chain is empty, so i have to create pf rules by myself!

I have seen the behavior that quasar is talking about before on some Astaro units (not just this beta)... normally the Astaro automatically creates packet filter rules (hidden) so that the DNS Server on the Astaro ITSELF can do lookups on the internet... sometimes this doesn't happen, or the rule gets put in the wrong place... I believe that is what he is describing, trollvotel.

That said, I didn't have that problem here on my beta installation... but I do have a few units in the field that, some time ago, I had to add a rule for the external interface of the Astaro to access DNS outbound for it's own built in DNS Server / Proxy.

thats exactly what i meant. thanks!

Any hint how to recover normal behaviour?

i found something in /tmp/mdwdebug.log:

iptables-restore v1.3.5: host/network `' not found

Error occurred at line: 12

Try `iptables-restore -h' or 'iptables-restore --help' for more information.

12:  -A AUTO_OUTPUT -d /255.255.255.255 -p tcp --sport 1:65535 --dport 443    -j CONFIRMED

the ip is missing, thus the iptables-restore doesn't work. maybe a wrong initialized variable? maybe it has something to do with site-2-site ssl because of the destination port.

Well observed! This is probably caused by a bug in the code that sets packet filter rules for SSL site-to-site VPN client connections. That bug is fixed already but the fix is not released, yet.

You can try if things work out for you after you disabled all SSL site-to-site client connections. If so, you may want to override the server address at the client connection settings dialog using an IP address. The bug is triggered when DNS hostnames come into play.

The final fix will come with the next beta.

Sorry for the inconvenience.

Well observed! This is probably caused by a bug in the code that sets packet filter rules for SSL site-to-site VPN client connections. That bug is fixed already but the fix is not released, yet.

You can try if things work out for you after you disabled all SSL site-to-site client connections. If so, you may want to override the server address at the client connection settings dialog using an IP address. The bug is triggered when DNS hostnames come into play.

The final fix will come with the next beta.

Sorry for the inconvenience.