Internet access on VMs behind SDNAT4

Integration Support Marketplace Appliances
1

Good Day!

I would like to ask if this guide right here: vr_sdnat4 · OpenNebula/one-apps Wiki · GitHub is still applicable in setting up SDNAT4 for my virtual router on OpenNebula 7.0 or is there a much more updated guide? or if there is something missing on the guide?

The reason that i ask is i was able to actually follow through this guide for the most part but my vms do not get internet access. I’m sure that i have followed everything in here so im kind of stuck. Please see screenshots below as a proof that i have actually set it up based on the guide github guide that i have linked.

VROUTER:
NIC 0: virtual network for public - bridged - no mac/ip spoofing filter enable
NIC 1: private host networking
NIC 2: vlan for onegate

image
image860×370 7.9 KB

image
image891×145 2 KB

image
image600×546 9.16 KB

On My Alpine VM

image
image1028×771 14.5 KB

Thanks in advance…

2

Hi!
We have to check actual packets flow and identity at which step issue is happening. So could you please do the following:

  1. Start ping to any external host, f.e. 1.1.1.1 from your alpine machine
  2. Capture traffic using tcpdump on vrouter on both internal and external interfaces
  3. Share both captures output in this thread
3

Thanks Dmitriy. i managed to resolve one of the issue where the dns resolution on the vm is failing by adding some context variables on the vrouter based on this documentation. vr_dns · OpenNebula/one-apps Wiki · GitHub

image
image722×457 12.1 KB

although my vm still doesnt seem to have a proper internet access and when checking the traffic using tcpdump on the vrouter, i’m noticing some weird behavior wherein the hypervisor’s ip is the one showing as the source when attempting a ping from the alpine vm. see tcpdump log below.

NOTE:
the ip 10.20.30.141 is the hypervisor’s ip address and not the vrouter’s (10.20.30.155) nor the alpine vm (10.20.30.156)

vm-vrouter-001-0:~$ sudo tcpdump -v -i eth1 port not 22
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:45:58.176989 IP (tos 0x0, ttl 64, id 5269, offset 0, flags [DF], proto UDP (17), length 59)
    172.16.100.2.34859 > 172.16.100.1.53: 22197+ A? opennebula.io. (31)
13:45:58.176999 IP (tos 0x0, ttl 64, id 5270, offset 0, flags [DF], proto UDP (17), length 59)
    172.16.100.2.34859 > 172.16.100.1.53: 61231+ AAAA? opennebula.io. (31)
13:45:58.178305 IP (tos 0x0, ttl 64, id 14980, offset 0, flags [none], proto UDP (17), length 75)
    172.16.100.1.53 > 172.16.100.2.34859: 22197 1/0/0 opennebula.io. A 74.207.243.79 (47)
13:45:58.208336 IP (tos 0x0, ttl 64, id 14982, offset 0, flags [none], proto UDP (17), length 87)
    172.16.100.1.53 > 172.16.100.2.34859: 61231 1/0/0 opennebula.io. AAAA 2600:3c01::f03c:94ff:fe6a:8aac (59)
13:45:58.214327 IP (tos 0x0, ttl 64, id 27934, offset 0, flags [DF], proto ICMP (1), length 84)
    10.20.30.141 > 74-207-243-79.ip.linodeusercontent.com: ICMP echo request, id 4, seq 0, length 64
13:45:59.215216 IP (tos 0x0, ttl 64, id 28012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.20.30.141 > 74-207-243-79.ip.linodeusercontent.com: ICMP echo request, id 4, seq 1, length 64
13:46:00.216253 IP (tos 0x0, ttl 64, id 28070, offset 0, flags [DF], proto ICMP (1), length 84)
    10.20.30.141 > 74-207-243-79.ip.linodeusercontent.com: ICMP echo request, id 4, seq 2, length 64
13:46:01.216854 IP (tos 0x0, ttl 64, id 28163, offset 0, flags [DF], proto ICMP (1), length 84)
    10.20.30.141 > 74-207-243-79.ip.linodeusercontent.com: ICMP echo request, id 4, seq 3, length 64
13:46:02.217280 IP (tos 0x0, ttl 64, id 28204, offset 0, flags [DF], proto ICMP (1), length 84)
    10.20.30.141 > 74-207-243-79.ip.linodeusercontent.com: ICMP echo request, id 4, seq 4, length 64

the current “public” vnet that i am using for the vrouter is just a simple bridge connection from the hypervisor’s ethernet interface (which is directly connected to my physical router). Also i’m pretty sure that i have not configured any ip masquerading on the hypervisor as well.

WIth all that said, thanks for checking this out and i’m looking forward for any suggestions :smiley:

4

Update:

Managed to make it work using OpenvSwitch on the private vnet with host only networking opiton ticked as well instead of the plain bridge host only networking.

image
image1379×522 17.9 KB

now i could ping anywhere from the vm and tcpdump shows the correct “source”

vr-test-ovs-0:~$ sudo tcpdump -i eth1 ## this is the vrouter
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:54:18.321130 IP 172.16.0.101.42116 > 172.16.0.100.53: 33242+ [1au] NS? . (40)
18:54:18.321941 IP 172.16.0.100.53 > 172.16.0.101.42116: 33242 13/0/27 NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net., NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net. (811)
18:54:23.326678 ARP, Request who-has 172.16.0.100 tell 172.16.0.101, length 28
18:54:23.326821 ARP, Reply 172.16.0.100 is-at 02:00:ac:10:00:64 (oui Unknown), length 28
18:54:23.395216 ARP, Request who-has 172.16.0.101 tell 172.16.0.100, length 28
18:54:23.395555 ARP, Reply 172.16.0.101 is-at 02:00:ac:10:00:65 (oui Unknown), length 28
18:54:25.004953 IP 172.16.0.101.56888 > 172.16.0.100.53: 10207+ [1au] A? facebook.com. (53)
18:54:25.042706 IP 172.16.0.100.53 > 172.16.0.101.56888: 10207 1/0/1 A 163.70.130.35 (57)
18:54:30.334608 IP 172.16.0.101.46666 > 172.16.0.100.53: 25825+ A? facebook.com. (30)
18:54:30.334616 IP 172.16.0.101.46666 > 172.16.0.100.53: 32858+ AAAA? facebook.com. (30)
18:54:30.335334 IP 172.16.0.100.53 > 172.16.0.101.46666: 25825 1/0/0 A 163.70.130.35 (46)
18:54:30.382649 IP 172.16.0.100.53 > 172.16.0.101.46666: 32858 1/0/0 AAAA 2a03:2880:f17e:180:face:b00c:0:25de (58)
18:54:30.391534 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 0, length 64
18:54:30.408485 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 0, length 64
18:54:31.392601 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 1, length 64
18:54:31.405015 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 1, length 64
18:54:32.393234 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 2, length 64
18:54:32.404942 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 2, length 64
18:54:33.393613 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 3, length 64
18:54:33.399996 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 3, length 64
18:54:34.394099 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 4, length 64
18:54:34.433542 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 4, length 64
18:54:35.394584 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 5, length 64
18:54:35.425025 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 5, length 64
18:54:36.395184 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 6, length 64
18:54:36.433509 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 6, length 64
18:54:37.395616 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 7, length 64
18:54:37.425312 IP edge-star-mini-shv-02-mnl1.facebook.com > 172.16.0.101: ICMP echo reply, id 3, seq 7, length 64
18:54:38.396375 IP 172.16.0.101 > edge-star-mini-shv-02-mnl1.facebook.com: ICMP echo request, id 3, seq 8, length 64
5

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.