[
https://issues.apache.org/jira/browse/CLOUDSTACK-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bierce updated CLOUDSTACK-8541:
-------------------------------------
Description:
I was able to create this issue on a VPC network. It appears there are NAT
rules in place to grab all traffic from the PPP interfaces and forward them to
the PPP endpoint address. Unfortunately, the tunnel isn't create until dnsmasq
has already started.
It looks easy to patch, either a hook into ip-up for the tunnels to restart
dnsmasq what a new tunnel opens, change ppp to push a DNS server rather than
using using IPtables DNAT, or change it dns mask to listen to *:53
Included is an email from the mailing list of someone describing the issue in
2014, I couldn't find resolution any where, but this behavor makes it seem
remote users through VPCs has not worked for a long time.
Hi,
When I connect to CloudStack's VPN on a network (L2TP over IPSEC), I’m assigned
an IP like
10.1.2.2 and the DNS assigned is 10.1.2.1, but the virtual router is not
listening on this
IP (VPN) for DNS queries but on guest network so I cannot access resources by
using internal
dns domain names.
Is this normal behaviour? If it’s not a bug should we fix it? A workaround was
to set the
necessary DNS IP in the client before connecting (in my case the router’s IP,
10.1.1.1).
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | [email protected]
Blog: bhaisaab.org | Twitter: @_bhaisaab
was:
I was able to create this issue on a VPC network. It appears there are NAT
rules in place to grab all traffic from the PPP interfaces and forward them to
the PPP endpoint address. Unfortunately, the tunnel isn't create until dnsmasq
has already started.
It looks easy to patch, either a hook into ip-up for the tunnels to restart
dnsmasq what a new tunnel opens, change ppp to push a DNS server rather than
using using IPtables DNAT, or change it dns mask to listen to *:53
Hi,
When I connect to CloudStack's VPN on a network (L2TP over IPSEC), I’m assigned
an IP like
10.1.2.2 and the DNS assigned is 10.1.2.1, but the virtual router is not
listening on this
IP (VPN) for DNS queries but on guest network so I cannot access resources by
using internal
dns domain names.
Is this normal behaviour? If it’s not a bug should we fix it? A workaround was
to set the
necessary DNS IP in the client before connecting (in my case the router’s IP,
10.1.1.1).
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | [email protected]
Blog: bhaisaab.org | Twitter: @_bhaisaab
> Issue with accessing DNS from VPN IP
> ------------------------------------
>
> Key: CLOUDSTACK-8541
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8541
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Reporter: David Bierce
> Priority: Critical
>
> I was able to create this issue on a VPC network. It appears there are NAT
> rules in place to grab all traffic from the PPP interfaces and forward them
> to the PPP endpoint address. Unfortunately, the tunnel isn't create until
> dnsmasq has already started.
> It looks easy to patch, either a hook into ip-up for the tunnels to restart
> dnsmasq what a new tunnel opens, change ppp to push a DNS server rather than
> using using IPtables DNAT, or change it dns mask to listen to *:53
> Included is an email from the mailing list of someone describing the issue in
> 2014, I couldn't find resolution any where, but this behavor makes it seem
> remote users through VPCs has not worked for a long time.
> Hi,
> When I connect to CloudStack's VPN on a network (L2TP over IPSEC), I’m
> assigned an IP like
> 10.1.2.2 and the DNS assigned is 10.1.2.1, but the virtual router is not
> listening on this
> IP (VPN) for DNS queries but on guest network so I cannot access resources by
> using internal
> dns domain names.
> Is this normal behaviour? If it’s not a bug should we fix it? A workaround
> was to set the
> necessary DNS IP in the client before connecting (in my case the router’s IP,
> 10.1.1.1).
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | [email protected]
> Blog: bhaisaab.org | Twitter: @_bhaisaab
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
