Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion

Speeding up NAT on local bridged KVM to external port possible?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Speeding up NAT on local bridged KVM to external port possible?

WSSWSS Member
edited March 2017 in Help

Hi Guys,

I've setup my own services-in-KVM on a cheap KS machine which is completely overspec'd for the nameserver I'm going to be using it as. I've got my NIC setup as a bridge, and my clients each have their own unique MAC address. This is simple, and seems to work the easiest (as well as make the most sense).

The problem I have, though, is that there is a minimal-but existent delay between the host to the KVM, forwarding both TCP and UDP to port 53. Obviously, this is NOT ideal, but I can't really think of a better way of doing this.

Here's a broken-apart snippit of iptables on the host to allow UDP/TCP on 53:

/sbin/iptables -A PREROUTING -t nat -i br0 -p tcp --dport 53 -j DNAT --to 192.168.0.100:53
/sbin/iptables -A PREROUTING -t nat -i br0 -p udp --dport 53 -j DNAT --to 192.168.0.100:53
/sbin/iptables -A FORWARD -p tcp -d 192.168.0.100 --dport 53 -j ACCEPT
/sbin/iptables -A FORWARD -p udp -d 192.168.0.100 --dport 53 -j ACCEPT

I'm aware that packets on the bridge can be queued through iptables twice since it hits iptables' INPUT, and then a second time after it sees that the virtual MAC is a local destination. So, I've got this beauty setup so it only goes through once. Keep in mind that the verbs for broute are stupidly named (DROP means frame has to be routed, ACCEPT means frame has to be bridged).

/sbin/ebtables -t broute -A BROUTING -d my:br:mac:address:goes:here -j redirect --redirect-target DROP

I've yet to have it drop or lose any UDP packets before the client moves on to the next host, but it just isn't snappy. What can I do to get this just a bit faster?

Edit: Client OS is OpenBSD running native virtio drivers on both client and host.

Comments

  • For my own setup it suffices to just have the top 2 iptables lines. Maybe the last 2 lines are redundant and cause the delay?

    Disclaimer: my iptables rules are copy pasted from random places all over the interwebz.

  • WSSWSS Member

    You don't make sure your outgoing messages go back to the client? I'm kind of paranoid because iptables sucks.

    If you have yours setup as a KVM, try the ebtables that I've got going and see if you can find any difference. It /does/ reduce one run through iptables.

  • @WSS said:
    You don't make sure your outgoing messages go back to the client? I'm kind of paranoid because iptables sucks.

    Never had any issues with it, using for tcp and udp. VM wants to send back a message to [insert external ip here] and the lxc software takes care of it for me. (not running KVM)

  • WSSWSS Member

    Gotcha.

  • @WSS said:
    Gotcha.

    You mean "I understand your setup" or you mean "That stuff fixed it"?

  • WSSWSS Member

    @teamacc said:

    @WSS said:
    Gotcha.

    You mean "I understand your setup" or you mean "That stuff fixed it"?

    The first.

Sign In or Register to comment.