Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 1451 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 does not forward DNS (rule / nat conflict?)

MatthiasFleschuetz
Hi Forum,

we have the problem with the following scenario:
- SITE A:
  * primary ns server for domain
  * ASG-120 gateway with 5.200
  * dynamic IP
  * DNS proxy for Site A LAN

- SITE B:
  * secondary ns server for comain
  * ASL with 5.203
  * fix IP
  * DNS proxy for Site B LAn
  * DNAT rules for DNS service from internet to NS-server in LAN
  * SNAT rules for DNS service from NS-server in LAN to internet servers, mapping this traffic to another ip than our MASQ-internet.

What works:
  * RSA net-to-net VPN
  * nearly all tested services working (RDP, HTTP, HTTPS, ...)
  * any service allowed in both directions on both sites

The problem:
  ! NS traffic is not going through the VPN

Description:
Every NS-traffic-packet which should enter the tunnel seems to leave the Site B Astaro but not arriving at Site A Astaro.
I see "allowed" entries in the LiveLog on Site B which says there is UDP traffic on port 53 from secondary ns server to primary ns server.
But I dont see any log entry in the LoveLog of Site A which prints _ANY_ incoming packet! This is also the same if I drop any traffic between both sites and log this, there is also no "deny" log.

Thats why I think that there is some conflict with any other rule, nat-rule or config on site b, because it seems that the packet is really not going INTO the tunnel as no such packet is coming out on Site A).

Does anybody has a hint or experiences with such an conflict?!?!?

Thanks a lot,

Matthias Eichler


This thread was automatically locked due to age.
Parents
  • 0
    > Does anybody has a hint or experiences with such an conflict?!?!?

    Yes, maybe ...

    By the way, where can I find that cute "LoveLog" you wrote about  . If it is a typo, it would be a greate feature request  .
    Ok, just kidding.

    I assume you are making zone transfers and things like that. Anyway the DNS proxy is not used for that traffic. Is that right?
    Is there a masquerading for the network in which the NS is placed in? This masquerading masquerades all traffic to the external IP address of the Astaro in order to make websurfing possible. Right?  If the tunnel is not established, also NS packets on udp are maqueraded. If then the tunnel establishes, the udp lifetime is not over yet and so the packets are still masqueraded, because they belong to the same old connection (connection tracking). The connection has to time out in order to get a new connection tracking which does not masquerade. In case of a highly frequented NS, the connection tracking does never time out, because there is always traffic which refreshes the old connection. The lifetime of udp is 30 seconds.
    So lets try the following. Establish the tunnel, then cut the NS traffic for at least 30 seconds. Then start the NS traffic again. You can see all the connection tracking entries in /proc/net/ip_conntrack or Webadmin -> Packet Filter -> Advanced -> Connection Tracking Table.
    The problem does not happen for tcp.

    One addition. I just read your article again. Of course, in your case the problem might be related to the SNAT rule also. Not only to the masquerading rule. Basically a masquerading would do the same as your SNAT rule. So it's maybe the same problem but related to the SNAT instead of the masquerading basically is also a SNAT.

    Xeno
  • 0 in reply to Xeno
    Thanks for that hint with the connection table...I simply forgot this feature.
    Unfortunately it has not directly to do with that time window, would have been strange in my eyes if it was, because there has never been such a connection before (SRC-IP:53 -> DST-IP:53), so why should it fall under existing connections?!?

    But I saw the following:
    my SNAT-rule conflicts with my VPN!
    Meaning: I am masquerading my DNS-servers at SITE B) behind a dedicated official IP, and not behind the same IP where all other traffic is masqueraded.
    Due to that SNAT rule
    (DNS-SERVERS -> Any / DNS 
     offic_ns_ip -> None)
    the ns traffic that should go through the vpn tunnel is masqueraded like all outgoing (external) ns connections.

    This is again a point where I would like to have a "negate" option in rules (like in many other fw-products) for creating rules like "target any EXCEPTING network1"...[:(]
Reply
  • 0 in reply to Xeno
    Thanks for that hint with the connection table...I simply forgot this feature.
    Unfortunately it has not directly to do with that time window, would have been strange in my eyes if it was, because there has never been such a connection before (SRC-IP:53 -> DST-IP:53), so why should it fall under existing connections?!?

    But I saw the following:
    my SNAT-rule conflicts with my VPN!
    Meaning: I am masquerading my DNS-servers at SITE B) behind a dedicated official IP, and not behind the same IP where all other traffic is masqueraded.
    Due to that SNAT rule
    (DNS-SERVERS -> Any / DNS 
     offic_ns_ip -> None)
    the ns traffic that should go through the vpn tunnel is masqueraded like all outgoing (external) ns connections.

    This is again a point where I would like to have a "negate" option in rules (like in many other fw-products) for creating rules like "target any EXCEPTING network1"...[:(]
Children
Cookie Information Banner