IPTables redirect all UDP packets including ESTABLISHED












3















We currently have some rules setup in IPtables that look like the below:



-A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j REDIRECT --to-ports 21010


This redirects packets containing that payload to our caching programs, this works great. However, only "new" packets are hitting this NAT rule. After some looking around, I managed to solve this issue by setting the following:



sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=0
sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=0


This introduced another problem where ALL UDP packets were being set to this. During a small UDP flood, this would cause all udp traffic on the server to halt.



I'm needing to redirect ALL UDP packets containing a certain payload to another port on the same machine. We have another program listening on this port that replies to this payload. This is due to a query flood that usually freezes up one of our applications, so we offload this query to another program.



Any solutions to this? Been looking around for months without any sort of answer.










share|improve this question

























  • I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

    – roaima
    Nov 18 '16 at 18:18













  • NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

    – user1372896
    Nov 18 '16 at 18:32











  • I basically just need a way to redirect UDP packets containing x payload to another port

    – user1372896
    Nov 18 '16 at 18:36











  • I would suggest then that you edit your question to remove the "without NAT" stipulation.

    – roaima
    Nov 18 '16 at 22:49






  • 1





    Can you edit the question and add you all rules in the NAT table ?

    – Wissam Roujoulah
    Nov 19 '16 at 4:58
















3















We currently have some rules setup in IPtables that look like the below:



-A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j REDIRECT --to-ports 21010


This redirects packets containing that payload to our caching programs, this works great. However, only "new" packets are hitting this NAT rule. After some looking around, I managed to solve this issue by setting the following:



sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=0
sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=0


This introduced another problem where ALL UDP packets were being set to this. During a small UDP flood, this would cause all udp traffic on the server to halt.



I'm needing to redirect ALL UDP packets containing a certain payload to another port on the same machine. We have another program listening on this port that replies to this payload. This is due to a query flood that usually freezes up one of our applications, so we offload this query to another program.



Any solutions to this? Been looking around for months without any sort of answer.










share|improve this question

























  • I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

    – roaima
    Nov 18 '16 at 18:18













  • NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

    – user1372896
    Nov 18 '16 at 18:32











  • I basically just need a way to redirect UDP packets containing x payload to another port

    – user1372896
    Nov 18 '16 at 18:36











  • I would suggest then that you edit your question to remove the "without NAT" stipulation.

    – roaima
    Nov 18 '16 at 22:49






  • 1





    Can you edit the question and add you all rules in the NAT table ?

    – Wissam Roujoulah
    Nov 19 '16 at 4:58














3












3








3


2






We currently have some rules setup in IPtables that look like the below:



-A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j REDIRECT --to-ports 21010


This redirects packets containing that payload to our caching programs, this works great. However, only "new" packets are hitting this NAT rule. After some looking around, I managed to solve this issue by setting the following:



sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=0
sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=0


This introduced another problem where ALL UDP packets were being set to this. During a small UDP flood, this would cause all udp traffic on the server to halt.



I'm needing to redirect ALL UDP packets containing a certain payload to another port on the same machine. We have another program listening on this port that replies to this payload. This is due to a query flood that usually freezes up one of our applications, so we offload this query to another program.



Any solutions to this? Been looking around for months without any sort of answer.










share|improve this question
















We currently have some rules setup in IPtables that look like the below:



-A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j REDIRECT --to-ports 21010


This redirects packets containing that payload to our caching programs, this works great. However, only "new" packets are hitting this NAT rule. After some looking around, I managed to solve this issue by setting the following:



sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=0
sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=0


This introduced another problem where ALL UDP packets were being set to this. During a small UDP flood, this would cause all udp traffic on the server to halt.



I'm needing to redirect ALL UDP packets containing a certain payload to another port on the same machine. We have another program listening on this port that replies to this payload. This is due to a query flood that usually freezes up one of our applications, so we offload this query to another program.



Any solutions to this? Been looking around for months without any sort of answer.







iptables nat netfilter iptables-redirect






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 '16 at 1:32







user1372896

















asked Nov 16 '16 at 17:18









user1372896user1372896

164




164













  • I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

    – roaima
    Nov 18 '16 at 18:18













  • NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

    – user1372896
    Nov 18 '16 at 18:32











  • I basically just need a way to redirect UDP packets containing x payload to another port

    – user1372896
    Nov 18 '16 at 18:36











  • I would suggest then that you edit your question to remove the "without NAT" stipulation.

    – roaima
    Nov 18 '16 at 22:49






  • 1





    Can you edit the question and add you all rules in the NAT table ?

    – Wissam Roujoulah
    Nov 19 '16 at 4:58



















  • I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

    – roaima
    Nov 18 '16 at 18:18













  • NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

    – user1372896
    Nov 18 '16 at 18:32











  • I basically just need a way to redirect UDP packets containing x payload to another port

    – user1372896
    Nov 18 '16 at 18:36











  • I would suggest then that you edit your question to remove the "without NAT" stipulation.

    – roaima
    Nov 18 '16 at 22:49






  • 1





    Can you edit the question and add you all rules in the NAT table ?

    – Wissam Roujoulah
    Nov 19 '16 at 4:58

















I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

– roaima
Nov 18 '16 at 18:18







I don't see how you can translate a network address without using NAT. What are your objections to using network address translation in some form?

– roaima
Nov 18 '16 at 18:18















NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

– user1372896
Nov 18 '16 at 18:32





NAT is fine, except it needs to redirect all matching packets and not just NEW ones. Established connections etc do not go through NAT

– user1372896
Nov 18 '16 at 18:32













I basically just need a way to redirect UDP packets containing x payload to another port

– user1372896
Nov 18 '16 at 18:36





I basically just need a way to redirect UDP packets containing x payload to another port

– user1372896
Nov 18 '16 at 18:36













I would suggest then that you edit your question to remove the "without NAT" stipulation.

– roaima
Nov 18 '16 at 22:49





I would suggest then that you edit your question to remove the "without NAT" stipulation.

– roaima
Nov 18 '16 at 22:49




1




1





Can you edit the question and add you all rules in the NAT table ?

– Wissam Roujoulah
Nov 19 '16 at 4:58





Can you edit the question and add you all rules in the NAT table ?

– Wissam Roujoulah
Nov 19 '16 at 4:58










1 Answer
1






active

oldest

votes


















0














I have two completely different methods to solve this problem:



iptables with conntrack zones



Contrack zones allow multiple conntrack instances (per network namespace).



By adding an orig-zone tag to the packet and thus flow, it's possible to have two conntrack instances splitting the (half created) flow in two parts: the normal packets and the matching packets, each in its own flow. Thus usual NAT rules will continue to work and can happen twice instead of once: once for the normal packets and once for the matching packets.



Instead of duplicating the test, a mark will be put in place after the one test done on the packet.



iptables -t raw -A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j MARK --set-mark 1
iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-orig 1
iptables -t nat -A PREROUTING -p udp -m mark --mark 1 -j REDIRECT --to-ports 21010


Example of conntrack results:



# conntrack -E -p udp --orig-port-dst 27035
[NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
[NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670
[UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
[UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670




nftables with notrack and packet header field mangling



requires kernel >= 4.10



(Of course the zones method could be implemented with nftables).



Here NAT is done statelessly, with conntrack disabled, for matching incoming packets and all outgoing reply packets from the redirected port.



nft add table ip raw
nft add chain ip raw prerouting '{type filter hook prerouting priority -300;}'
nft add chain ip raw output '{type filter hook output priority -300;}'
nft add rule ip raw prerouting ip daddr dstip/32 udp dport 27035 @th,64,32 == 0xffffffff @th,96,32 == 0x54536f75 @th,128,32 == 0x72636520 @th,160,32 == 0x456e6769 @th,192,32 == 0x6e652051 @th,224,32 == 0x75657279 notrack udp dport set 21010
nft add rule ip raw output udp sport 21010 notrack udp sport set 27035


(note that the u32 equivalent raw payload filters can be simplified and are actually simplified automatically by nftables: it appears nftables handles u128 internally as can be seen with nft --debug=netlink list ruleset -a).






share|improve this answer

























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f323758%2fiptables-redirect-all-udp-packets-including-established%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I have two completely different methods to solve this problem:



    iptables with conntrack zones



    Contrack zones allow multiple conntrack instances (per network namespace).



    By adding an orig-zone tag to the packet and thus flow, it's possible to have two conntrack instances splitting the (half created) flow in two parts: the normal packets and the matching packets, each in its own flow. Thus usual NAT rules will continue to work and can happen twice instead of once: once for the normal packets and once for the matching packets.



    Instead of duplicating the test, a mark will be put in place after the one test done on the packet.



    iptables -t raw -A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j MARK --set-mark 1
    iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-orig 1
    iptables -t nat -A PREROUTING -p udp -m mark --mark 1 -j REDIRECT --to-ports 21010


    Example of conntrack results:



    # conntrack -E -p udp --orig-port-dst 27035
    [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
    [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670
    [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
    [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670




    nftables with notrack and packet header field mangling



    requires kernel >= 4.10



    (Of course the zones method could be implemented with nftables).



    Here NAT is done statelessly, with conntrack disabled, for matching incoming packets and all outgoing reply packets from the redirected port.



    nft add table ip raw
    nft add chain ip raw prerouting '{type filter hook prerouting priority -300;}'
    nft add chain ip raw output '{type filter hook output priority -300;}'
    nft add rule ip raw prerouting ip daddr dstip/32 udp dport 27035 @th,64,32 == 0xffffffff @th,96,32 == 0x54536f75 @th,128,32 == 0x72636520 @th,160,32 == 0x456e6769 @th,192,32 == 0x6e652051 @th,224,32 == 0x75657279 notrack udp dport set 21010
    nft add rule ip raw output udp sport 21010 notrack udp sport set 27035


    (note that the u32 equivalent raw payload filters can be simplified and are actually simplified automatically by nftables: it appears nftables handles u128 internally as can be seen with nft --debug=netlink list ruleset -a).






    share|improve this answer






























      0














      I have two completely different methods to solve this problem:



      iptables with conntrack zones



      Contrack zones allow multiple conntrack instances (per network namespace).



      By adding an orig-zone tag to the packet and thus flow, it's possible to have two conntrack instances splitting the (half created) flow in two parts: the normal packets and the matching packets, each in its own flow. Thus usual NAT rules will continue to work and can happen twice instead of once: once for the normal packets and once for the matching packets.



      Instead of duplicating the test, a mark will be put in place after the one test done on the packet.



      iptables -t raw -A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j MARK --set-mark 1
      iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-orig 1
      iptables -t nat -A PREROUTING -p udp -m mark --mark 1 -j REDIRECT --to-ports 21010


      Example of conntrack results:



      # conntrack -E -p udp --orig-port-dst 27035
      [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
      [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670
      [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
      [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670




      nftables with notrack and packet header field mangling



      requires kernel >= 4.10



      (Of course the zones method could be implemented with nftables).



      Here NAT is done statelessly, with conntrack disabled, for matching incoming packets and all outgoing reply packets from the redirected port.



      nft add table ip raw
      nft add chain ip raw prerouting '{type filter hook prerouting priority -300;}'
      nft add chain ip raw output '{type filter hook output priority -300;}'
      nft add rule ip raw prerouting ip daddr dstip/32 udp dport 27035 @th,64,32 == 0xffffffff @th,96,32 == 0x54536f75 @th,128,32 == 0x72636520 @th,160,32 == 0x456e6769 @th,192,32 == 0x6e652051 @th,224,32 == 0x75657279 notrack udp dport set 21010
      nft add rule ip raw output udp sport 21010 notrack udp sport set 27035


      (note that the u32 equivalent raw payload filters can be simplified and are actually simplified automatically by nftables: it appears nftables handles u128 internally as can be seen with nft --debug=netlink list ruleset -a).






      share|improve this answer




























        0












        0








        0







        I have two completely different methods to solve this problem:



        iptables with conntrack zones



        Contrack zones allow multiple conntrack instances (per network namespace).



        By adding an orig-zone tag to the packet and thus flow, it's possible to have two conntrack instances splitting the (half created) flow in two parts: the normal packets and the matching packets, each in its own flow. Thus usual NAT rules will continue to work and can happen twice instead of once: once for the normal packets and once for the matching packets.



        Instead of duplicating the test, a mark will be put in place after the one test done on the packet.



        iptables -t raw -A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j MARK --set-mark 1
        iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-orig 1
        iptables -t nat -A PREROUTING -p udp -m mark --mark 1 -j REDIRECT --to-ports 21010


        Example of conntrack results:



        # conntrack -E -p udp --orig-port-dst 27035
        [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
        [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670
        [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
        [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670




        nftables with notrack and packet header field mangling



        requires kernel >= 4.10



        (Of course the zones method could be implemented with nftables).



        Here NAT is done statelessly, with conntrack disabled, for matching incoming packets and all outgoing reply packets from the redirected port.



        nft add table ip raw
        nft add chain ip raw prerouting '{type filter hook prerouting priority -300;}'
        nft add chain ip raw output '{type filter hook output priority -300;}'
        nft add rule ip raw prerouting ip daddr dstip/32 udp dport 27035 @th,64,32 == 0xffffffff @th,96,32 == 0x54536f75 @th,128,32 == 0x72636520 @th,160,32 == 0x456e6769 @th,192,32 == 0x6e652051 @th,224,32 == 0x75657279 notrack udp dport set 21010
        nft add rule ip raw output udp sport 21010 notrack udp sport set 27035


        (note that the u32 equivalent raw payload filters can be simplified and are actually simplified automatically by nftables: it appears nftables handles u128 internally as can be seen with nft --debug=netlink list ruleset -a).






        share|improve this answer















        I have two completely different methods to solve this problem:



        iptables with conntrack zones



        Contrack zones allow multiple conntrack instances (per network namespace).



        By adding an orig-zone tag to the packet and thus flow, it's possible to have two conntrack instances splitting the (half created) flow in two parts: the normal packets and the matching packets, each in its own flow. Thus usual NAT rules will continue to work and can happen twice instead of once: once for the normal packets and once for the matching packets.



        Instead of duplicating the test, a mark will be put in place after the one test done on the packet.



        iptables -t raw -A PREROUTING -d dstip/32 -p udp -m udp --dport 27035 -m u32 --u32 "0x0>>0x16&0x3c@0x8=0xffffffff&&0x0>>0x16&0x3c@0xc=0x54536f75&&0x0>>0x16&0x3c@0x10=0x72636520&&0x0>>0x16&0x3c@0x14=0x456e6769&&0x0>>0x16&0x3c@0x18=0x6e652051&&0x0>>0x16&0x3c@0x1c=0x75657279" -j MARK --set-mark 1
        iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-orig 1
        iptables -t nat -A PREROUTING -p udp -m mark --mark 1 -j REDIRECT --to-ports 21010


        Example of conntrack results:



        # conntrack -E -p udp --orig-port-dst 27035
        [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
        [NEW] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 [UNREPLIED] src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670
        [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 src=10.0.3.66 dst=10.0.3.1 sport=27035 dport=52670
        [UPDATE] udp 17 30 src=10.0.3.1 dst=10.0.3.66 sport=52670 dport=27035 zone-orig=1 src=10.0.3.66 dst=10.0.3.1 sport=21010 dport=52670




        nftables with notrack and packet header field mangling



        requires kernel >= 4.10



        (Of course the zones method could be implemented with nftables).



        Here NAT is done statelessly, with conntrack disabled, for matching incoming packets and all outgoing reply packets from the redirected port.



        nft add table ip raw
        nft add chain ip raw prerouting '{type filter hook prerouting priority -300;}'
        nft add chain ip raw output '{type filter hook output priority -300;}'
        nft add rule ip raw prerouting ip daddr dstip/32 udp dport 27035 @th,64,32 == 0xffffffff @th,96,32 == 0x54536f75 @th,128,32 == 0x72636520 @th,160,32 == 0x456e6769 @th,192,32 == 0x6e652051 @th,224,32 == 0x75657279 notrack udp dport set 21010
        nft add rule ip raw output udp sport 21010 notrack udp sport set 27035


        (note that the u32 equivalent raw payload filters can be simplified and are actually simplified automatically by nftables: it appears nftables handles u128 internally as can be seen with nft --debug=netlink list ruleset -a).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 22 mins ago

























        answered 28 mins ago









        A.BA.B

        4,2721724




        4,2721724






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f323758%2fiptables-redirect-all-udp-packets-including-established%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Accessing regular linux commands in Huawei's Dopra Linux

            Can't connect RFCOMM socket: Host is down

            Kernel panic - not syncing: Fatal Exception in Interrupt