Bug #10820
closed
Extremely low speeds to vm's when using paravirtualized (xn*) interfaces on XenServer/XCP-ng
0%
Description
Hi,
I am experiencing an issue where I have extremely low speeds while accessing vm's behind a pfsense on a virtualized environment (XCP-ng 8.1).
After much much digging I have come across a few threads and topics describing this issue, some are pretty old and some more recent. One had the last activity in 2019 and suggested to also disable (on the dom0) ethtool-rx, not only the usually mentioned ethtool-tx documented for pfSense. (not sure if works I'll try that but was looking for a more definite solution).
I believe this is also causing another issue where I get packetloss events between the pfSense and dom0.
I have first posted my issue here: https://forum.netgate.com/topic/155834/issue-xcp-ng-routed-config-pfsense-slow-speed-packetloss
And also found this topic: https://forum.netgate.com/topic/77283/very-slow-traffic-from-other-vm-s-through-pfsense-on-xenserver
A similar situation on the FreeBSD Bug tracker (I was looking to apply the fix but without luck): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261
Thank you
Updated by Jim Pingle over 4 years ago
- Status changed from New to Needs Patch
If the patches get accepted into FreeBSD, they will make their way into pfSense down the road. Though I find it difficult to believe there is a general problem here as there are people out there using pfSense in Xen and that seems like a fairly common requirement. I wouldn't be so quick to leap to the conclusion that it's not something in your configuration or environment.
Updated by Ricardo Mendes over 4 years ago
Hi Jim thank you for your quick reply.
Regarding my configuration/environment, its a new setup with XCP-ng 8.1 at Hetzner.
It has one physical ethernet card, and a routed setup.
ip_forwarding is enabled by adding a conf file to /etc/sysctl.d and the rest of the configuration is on XCP-ng: a new interface for wan (/29) and other networks. ip address configuration with first usable ip from the subnet and pfsense has the second usable ip.
So this is as clean as it gets so far. iptables on host -i xenbr0 -o xenbr0 -j ACCEPT and access to pfSense is done without issues.
The remaining ip's of the /29 are configured as virtual ip's and two are being used on nat 1:1 with the corresponding rules as floating rules interface wan any to private server ip.
The pfSense also has an IPSec site-to-site VPN from my pfSense router to this pfSense. The VPN works fine, I can access the pfSense on the internal network it works fast, but if from a linux machine on the same xcp-ng host to access the pfsense is as painful as for me to access any other server behind the pfsense.
The server has 3 configured networks to which is acting as dhcp server. one is a public lan, a dmz and a management network. and i am still to add another for storage. the hosts in there have dhcp on and static leases configured on the pfsense.
They all get IP's, I can ssh to all. Sometimes it breaks and accessing web pages from vm's hosted there is just awful.
on the xcp-ng host side all the vif's that belong to this vm have the following settings on other-config:
xn0 - ethtool-rx: off; ethtool-tx: off
xn1 - ethtool-rx: off; ethtool-tx: off
xn2 - ethtool-rx: off; ethtool-tx: off
xn3 - ethtool-rx: off; ethtool-tx: off
I don't know if it is related to having a Realtek card, but the issue is exactly as described on so many other topics here and there. I don't have extra packages installed on the pfSense it was a plain install from the iso.
If you want me to provide more data I will. I won't mind trying to make some force to push this where it needs to go to get solved cause this issue is killing my sanity! Thank you!
Updated by Ricardo Mendes over 4 years ago
Hi,
A new update. the networks were configured for vlans configured at hetzner while using hetzner vswitch.
Creating new networks not bond to external vlans seems to offer normal performances.
Will have to take it to XCP-ng. Thanks.
Updated by Ricardo Mendes over 4 years ago
For future reference if someone comes across this issue, what was happening was that devices on my internal network weren't using the correct mtu size. And since all traffic was going through the vSwitch that required the proper mtu, this happened.
I had the Interfaces on interface assignment configured with MTU 1400 but that was not enough.
I had to go to Services > DHCP Server > Additional BOOTP/DHCP Options
Option 26 Unsigned 16 bit integer 1400
and it got fixed. The issue can be closed. Thanks.