Bug 1089078
| Summary: | network traffic of guests on libvirt NATed virtual network not properly forwarded across libreswan IPSec connection | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Matěj Cepl <mcepl> | ||||||||
| Component: | libreswan | Assignee: | Paul Wouters <pwouters> | ||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||||
| Severity: | low | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 8.1 | CC: | amarecek, dyuan, jaster, linville, mzhan, omoris, pvrabec, pwouters, tmraz | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | 8.1 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2019-08-06 13:31:06 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 1682518 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 887308 [details]
tcpdump output
Created attachment 887310 [details]
tcpdump output with OpenVPN
One more important data point ... connection to Red Hat network does work when the host is connected via OpenVPN (and not libreswan as in the previous case). I guess we rely too much on the existence of tun0?
(In reply to Matěj Cepl from comment #2) > Created attachment 887310 [details] > tcpdump output with OpenVPN > > One more important data point ... connection to Red Hat network does work > when the host is connected via OpenVPN (and not libreswan as in the previous > case). That is the crucial point. My guess is that libreswan (which uses IPSec) is possibly tapping into the network at too low a level. >I guess we rely too much on the existence of tun0? No part of libvirt or its network directly relies on tun0. What it does rely on is that traffic will be forwarded by the host IP stack according to the host's routing table. If libreswan is working at a level that ends up only dealing with locally-generated traffic, then it's not going to work for the guests. I'm curious what libreswan does to decide which traffic to forward through IPSec. I'll try installing libreswan on one of my Fedora boxes so that I can see for myself. In the meantime, is anything added to the routing table when you start the VPN connection? Paul, libvirt's guests are connecting to a Linux bridge device via tap devices, then relying on 1) iptables mangle rules (which mangle *all* IP protocols) to NAT traffic from the guests that has a destination off the bridge's subnet, and 2) the host IP stack to forward the traffic out towards its final destination. I'm unfamiliar with exactly where libreswan taps into the network traffic, so I'm hoping maybe you can help me understand - is this failure caused by libreswan grabbing traffic to be encapsulated at a point that forwarded traffic wouldn't be passing? Or could it be that the iptables packet mangling is happening at a point *after* libreswan is intercepting traffic (or maybe skipped completely in this case), resulting in un-NATed packets being encapsulated? (Can you provide some beginner's hints on how to examine exactly what packets are being encapsulated (since I'm unsure where libreswan sits wrt iptables and pcap, I don't know if the output of tcpdump would be of any use at all.) The IPsec does kick in before the NAT, so this is tricky. I had noticed this problem, but since I only needed repo access, I run a squid proxy on my host and tell my VMs to connect using yum via the proxy :P I just tried some things to make this work, but so far no luck. Let me think about this some more. Perhaps we could solve this by using the new(ish) VTI support to create a device, which would allow routing/natting into it more traditionally. I'll assign this to libreswan for now, as this is more of an IPsec than libvirt issue. Do we have any simple reproducer for this issue? punting to rhel-7.5 We are not able to reproduce this. |
Created attachment 887307 [details] mentioned screenshot Description of problem: I have a host computer (running RHEL-7 with libvirt-1.1.1-29.el7.x86_64 and kernel-3.10.0-116.el7.x86_64) which is connected to the Red Hat VPN via libreswan (or OpenVPN, I don't think it matters). While on guest, I can ping (or browse with Firefox) to sites on plain Internet (e.g., www.google.com), but I cannot ping to the sites on the internal Red Hat network (e.g., wiki.brq.redhat.com). I do get DNS resolution though (see the attached screenshot of Debian 7.2 running as a guest; but I can observe the same behavior with RHEL-6 and RHEL-7 on guests). I have also attached output of tcpdump -v -i any host 192.168.122.103 # that's IP address of the guest's network interface