[11:26] <bipul> Hi, could anyone help me to know why i'm not able to ping from A to D, since A, C and D all are running on Ubuntu-server. Is it a flaw in OpenVPN tap or? in routing https://pastebin.com/raw/fje2RFhc
[13:01] <cryptodan_mobile> bipul: are they pingable off openvpn
=== phunysanta is now known as phunyguy
[15:57] <jlacroix> Hello eveyrone. I am in the process of creating a VM template for Ubuntu Server 18.04. For some reason, if I delete /etc/machine-id, it's not regenerated automatically when the VM is started. I can regenerate it manually, but I was hoping there was a way for this to happen automatically at first boot.
[16:00] <OerHeks> i think dbus-uuidgen --ensure=/etc/machine-id is your answer https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
[16:00] <OerHeks> systemd-machine-id-setup
[16:05] <jlacroix> Thanks OerHeks, but that was the article I was already looking at. I know how to generate the machine ID manually, I was hoping to make it automatically happen. I tried deleting it but it doesn't create it when it starts. As for the systemd-machine-id-setup service, that's not available in Ubuntu 18.04 unless it requires a package to be installed
[16:06] <TJ-> jlacroix: systemd-machine-id-setup is in 18.04's systemd package, in /bin/
[16:07] <OerHeks> ah hard linking
[16:08] <jlacroix> Ah, I was able to find the systemd-machine-id now, thanks.
[16:09] <jlacroix> The problem though is that it's always generating the same id each time I run it, despite me deleting /etc/machine-id first
[16:11] <TJ-> did you read the man-page?
[16:12] <OerHeks> If this file is empty
[16:12] <OerHeks>        or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the  KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID.
[16:13] <jlacroix> Yes, I read it.
[16:14] <jlacroix> /var/lib/dbus/machine-id is simply a link to /etc/machine-id
[17:34] <bipul> cryptodan_mobile, Yes, at least the virtual interface created by OpenVPN from that i'm able to ping each others client/server and vice versa.
[17:54] <cryptodan> bipul: yes your issue would appear to be routing
[17:54] <cryptodan> bipul: i would ask in ##networking
[17:55] <bipul> i have asked, and it was not related to routing, all routing is seems okay
[17:56] <cryptodan> if it was then you would be able to ping  from a to d
[17:56] <cryptodan> and d to a
[17:56] <bipul> exactly. it was working well in tun mode, but not with tap mode
[17:56] <cryptodan> or maybe ask the OpenVPN people
[17:57] <bipul> I have asked and raise a bug as well
[17:57] <bipul> do we need to do bridging here??? i don't think so
[17:59] <cryptodan> id wait till openvpn gets back unless its mission critical
[18:01] <TJ-> bipul: what was the issue? I've seen you mention it in various channels over the last few days
[18:02] <bipul> TJ-, It was related to tap mode in OpenVPN . Please find the diagram. https://pastebin.com/raw/fje2RFhc
[18:04] <bipul> May be i should check the mac address of D at C, while pinging from A to D
[18:04] <TJ-> yeah, just got the pastebin link in ##networking... seems to me the problem is on A's routing table...
[18:04] <TJ-> bindi: "10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 " <--- looks wrong!
[18:05] <bipul> TJ-, So what would be the correct one??
[18:07] <bindi> wat
[18:07] <bindi> hi
[18:07] <bipul> I believe the gateway would be the tap0 IP on the client as well as on the server.
[18:08] <TJ-> bipul: In other words, have you checked whether C/D receive the pings from A using tcpdump? even if the reply doesn't get back to A?
[18:08] <bipul> Because this is the virtual interface created during running on OpenVPN
[18:08] <TJ-> bipul: also, double-check on C that forwarding is enabled on all the interfaces
[18:09] <bipul> TJ-, Yes, it's enabled inside /etc/sysctl.conf net.ipv4.ip_forward=1
[18:09] <TJ-> bipul: how about "for n in /proc/sys/net/ipv4/conf/*/forwarding; do echo $n=$(cat $n); done "
[18:09] <bipul> wait let me check,and share with you.
[18:10] <bipul> TJ-, The problem is with tap mode , not with tun mode.
[18:10] <TJ-> bipul: my strong recommendation is to deploy tcpdump on C, and later on D, and check whether it is replying, and if so, on which interface
[18:10] <bipul> sure i would definitely follow your suggestion. And get back to you.
[18:11] <TJ-> bipul: I realise that; tap is a virtual ethernet interface, but I'm recommending you check other things around this in case it gives clues.
[18:12] <bipul> I'm new to this tcpdump, would you suggest any link to go with it.
[18:14] <TJ-> bipul: wooa, on C, what is this about!? "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.1" ?
[18:15] <bipul> https://paste.ubuntu.com/p/HNy6m59jc8/
[18:15] <TJ-> bipul: that is going to conflict with "10.216.21.0/24 dev enp0s3 proto kernel scope link src 10.216.21.1 "
[18:16] <bipul> I believe 10.216.0.0/16 is network inside it i.e 10.216.0.0/16 { 10.216.21.0/24 }
[18:16] <TJ-> bipul: on C: "sudo tcpdump -ni tap0 icmp"
[18:16] <jelly> more specific routes take precedence, a route for /16 won't override a nested route for /24
[18:17] <TJ-> bipul: that 10.216.0.0/16 does NOT look correct; you're telling it to send packets for that subnet down tap0 (to A)
[18:18] <TJ-> bipul: THAT rule should be executed on A, not C
[18:18] <bipul> okay. So what would be for {C,D} to A
[18:18] <jelly> TJ-: oh, here, have an idiom: grep . /proc/sys/net/ipv4/conf/*/forwarding
[18:19] <bipul> okay. So what would be for {C,D} to A at C?
[18:49] <TJ-> bipul: sorry, been at dinner; have you made progress. Just looked at A and I think this is wrong too (wrong gateway - should be the IP address of the interface at the far end of the tunnel) "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.2" so I'd expect it to be "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.1"
[18:50] <bipul> okay, sure, i will try with your given solution.
[18:50] <bipul> TJ-, Thank you. And i would let you know the outcome :)
[18:55] <TJ-> bipul: I'll simulate your network in marionnet, see if I can reproduce
[18:59] <bipul> Oh thank you very much. At this moment i'm  doing some cryptanalysis,whole my vm  is busy , i have less resource. Otherwise i would let you know the result.
[19:00] <bipul> wow nice marionnet
[19:09] <bipul> s/cryptanalysis/ studying crypto
[19:09] <bipul> I will do it later, and let you know. :)
[19:52] <bipul> TJ-, YES, it works
[19:52] <bipul> it was routing issue :)
[19:52] <TJ-> bipul: :)
[19:53] <TJ-> bipul: simple when you think it through :P
[19:53] <bipul> :) wow thank you very much sir
[20:01] <cryptodan> you are welcome bipul
[20:41] <kinghat> is there another way to mount a share other than cifs?
[20:42] <kinghat> i guess node/npm over cifs doesnt function properly.
[20:42] <kinghat> just wondering if mounting it via some other method would be a workaround?
[20:51] <kinghat> specifically what happens when i try to install packages over the share: https://paste.debian.net/hidden/b15c702d/