Replies: 3 comments 3 replies
-
Several of us are having a similar issue with "lo is loopback device" - over here I'm just wondering, is lo.ipsec the best default interface to use, given this issue with loopback device: Should we be adding some other interface, perhaps via a hook script eg running and then set vpn_interface_name (ie whatever name is preferred) as the default interface? (adding the .ipsec protocol part where appropriate?) Basically, is there a better way to solve this that doesn't require users editing /etc/strongswan.d/charon/resolve.conf ? |
Beta Was this translation helpful? Give feedback.
-
I believe the last bit about split horizon dns can be resolved by using ~ceos.com.au as well as other corporate domains with a tilde as as DOMAIN statement on the dummy interface that we bring up on IPsec tunnel establishment. thus this DNS server will preferred to resolve the specified domain. also when this then the dummy interface is dropped by IPsec going down then these network preferences are extinguished automatically too. On 7 Jun 2024, at 11:30 AM, John Orr ***@***.***> wrote:
Thanks very much Tobias (and in case it wasn't clear, I'm the "john" that cureton mentioned).
You asked lots of good questions - which you no doubt know the answers to far better than me!
"What interface would you suggest that is available on basically all systems?" My thought would be to add one as cureton suggested - but only if dnsmasq can be updated to work with this?
"if you refer to systemd-resolved rejecting it, then ask its devs why they do that" - they've not yet addressed the ticket in which two of us are asking about this issue (linked in my first message)
"or why they tie DNS servers to interfaces in the first place" - I could guess "security" - but you'll know far better than me I imagine.
"But you already have the option to configure an interface that's available on your system and is accepted by systemd-resolved. What's the problem with that?" - not much - it felt like a regression from previous functionality (using non-systemd resolvconf) - and the interfaces I'm using change a bit depending if I'm on wifi or ethernet (over usb-c).
"I guess you could also install resolvconf or openresolv" - I did that with ubuntu 22, but it seems neither is available from Ubuntu for 23 or 24, so again, it didn't feel like the optimal solution.
Thanks for the suggestion re XFRM interfaces - I'm yet to explore that option.
Thanks for the comments re dummy interfaces - I read some discussions/issues about them.
It certainly sounds like a very complicated and frustrating domain - once again, thanks so much for all your time/efforts with it. Unsurprisingly I've still got no idea how things should ideally work - though it still feels like the might be scope for improvements, somewhere, since systemd's changes.
PS - I also hit a problem, using a dummy interface for the vpn, where a server had a different address on the public internet vs on my vpn. With the old resolvconf, bringing up the vpn automatically made me get the VPN-served ip address for that server - but using a dummy interface, I still got the public version. If I set iface in /etc/strongswan.d/charon/resolve.conf to my ethernet interface, it replaces the public DNS and this problem goes away - but dropping the VPN deletes all DNS settings on that interface... the old resolvconf really was a lot more functional - as I've mentioned in the systemd bug!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hey guys, some recent updates. I've made through it by deliberately enforcing manual DNS on my network connection and the problem magically went away. I just don't know what happens though. |
Beta Was this translation helpful? Give feedback.
-
So i'm using VPN provided from my university and it requires a specific DNS modification.
Since resolve plugin from what i'm concerned,
First, I'm using resolvconf provided by the systemd-resolved which is just a symlink to resolvctl with little luck. I think the configuration details have changed since some newer version of systemd. The issue happens here with this issue
Then, i gave a try with open-resolv also with little luck, with something like
So i guess the process is using ipsec role to launch resolvconf? If so, how can i manage to get around with that?
Beta Was this translation helpful? Give feedback.
All reactions