iptable matching rule for STUN/TURN traffic
Clash Royale CLAN TAG#URR8PPP up vote
0
down vote
favorite
I am looking for finding TURN/STUN packets coming on a 443 port.
According to the TURN RFC, Bytes 46 to 49 are TURN packet magic cookie '2112a442'. Here is the screenshot from wireshark where I found the STUN cookie to be from 46 to 49
I am using -m u32 --u32 "46=0x2112A442" but am not able to filter them.
Here is my complete iptable rule
-A PREROUTING -i eth0 -p tcp --dport 443 -m u32 --u32 "46=0x2112A442" -j REDIRECT --to-port 3478
Any Idea what I could be doing wrong?
iptables nat
edited Jun 6 at 6:27
muru
128k19269459
asked Jun 5 at 9:11
Mystic monk
53
add a comment |Â
up vote
0
down vote
favorite
I am looking for finding TURN/STUN packets coming on a 443 port.
According to the TURN RFC, Bytes 46 to 49 are TURN packet magic cookie '2112a442'. Here is the screenshot from wireshark where I found the STUN cookie to be from 46 to 49
I am using -m u32 --u32 "46=0x2112A442" but am not able to filter them.
Here is my complete iptable rule
-A PREROUTING -i eth0 -p tcp --dport 443 -m u32 --u32 "46=0x2112A442" -j REDIRECT --to-port 3478
Any Idea what I could be doing wrong?
iptables nat
edited Jun 6 at 6:27
muru
128k19269459
asked Jun 5 at 9:11
Mystic monk
53
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am looking for finding TURN/STUN packets coming on a 443 port.
According to the TURN RFC, Bytes 46 to 49 are TURN packet magic cookie '2112a442'. Here is the screenshot from wireshark where I found the STUN cookie to be from 46 to 49
I am using -m u32 --u32 "46=0x2112A442" but am not able to filter them.
Here is my complete iptable rule
-A PREROUTING -i eth0 -p tcp --dport 443 -m u32 --u32 "46=0x2112A442" -j REDIRECT --to-port 3478
Any Idea what I could be doing wrong?
iptables nat
edited Jun 6 at 6:27
muru
128k19269459
asked Jun 5 at 9:11
Mystic monk
53
I am looking for finding TURN/STUN packets coming on a 443 port.
According to the TURN RFC, Bytes 46 to 49 are TURN packet magic cookie '2112a442'. Here is the screenshot from wireshark where I found the STUN cookie to be from 46 to 49
I am using -m u32 --u32 "46=0x2112A442" but am not able to filter them.
Here is my complete iptable rule
-A PREROUTING -i eth0 -p tcp --dport 443 -m u32 --u32 "46=0x2112A442" -j REDIRECT --to-port 3478
Any Idea what I could be doing wrong?
iptables nat
edited Jun 6 at 6:27
muru
128k19269459
asked Jun 5 at 9:11
Mystic monk
53
edited Jun 6 at 6:27
muru
128k19269459
edited Jun 6 at 6:27
muru
128k19269459
edited Jun 6 at 6:27
muru
128k19269459
128k19269459
asked Jun 5 at 9:11
Mystic monk
53
asked Jun 5 at 9:11
Mystic monk
53
asked Jun 5 at 9:11
Mystic monk
53
53
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29
add a comment |Â
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
The iptables u32 module offsets are referenced to the packet minus the ethernet wrapper (minus the source and destination MAC, 6 bytes each, and the ether type, 2 bytes. Therefore your wireshark offset of 46 needs to adjusted by 14, and should be 32.
Now, for a sanity check, find the type of service byte, which we know from the u32 area of the man pages for iptables-extensions is at offset 9 and we also know is 0x11 (17) for UDP. It is at byte 0x17 (23) of your wireshark screenshot. Counting from there, we also get 32 as the offset you should be using.
EDIT 1: Since the protocol is UDP, you also need to adjust that part of your iptables command. So:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
EDIT 2: In your example wireshark screen shot, the destination port is 5004, not 443. So the iptables command still will not work for your particular packet example. Maybe this:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
answered Jun 6 at 14:07
Doug Smythies
6,24631426
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
The iptables u32 module offsets are referenced to the packet minus the ethernet wrapper (minus the source and destination MAC, 6 bytes each, and the ether type, 2 bytes. Therefore your wireshark offset of 46 needs to adjusted by 14, and should be 32.
Now, for a sanity check, find the type of service byte, which we know from the u32 area of the man pages for iptables-extensions is at offset 9 and we also know is 0x11 (17) for UDP. It is at byte 0x17 (23) of your wireshark screenshot. Counting from there, we also get 32 as the offset you should be using.
EDIT 1: Since the protocol is UDP, you also need to adjust that part of your iptables command. So:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
EDIT 2: In your example wireshark screen shot, the destination port is 5004, not 443. So the iptables command still will not work for your particular packet example. Maybe this:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
answered Jun 6 at 14:07
Doug Smythies
6,24631426
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
add a comment |Â
up vote
1
down vote
accepted
The iptables u32 module offsets are referenced to the packet minus the ethernet wrapper (minus the source and destination MAC, 6 bytes each, and the ether type, 2 bytes. Therefore your wireshark offset of 46 needs to adjusted by 14, and should be 32.
Now, for a sanity check, find the type of service byte, which we know from the u32 area of the man pages for iptables-extensions is at offset 9 and we also know is 0x11 (17) for UDP. It is at byte 0x17 (23) of your wireshark screenshot. Counting from there, we also get 32 as the offset you should be using.
EDIT 1: Since the protocol is UDP, you also need to adjust that part of your iptables command. So:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
EDIT 2: In your example wireshark screen shot, the destination port is 5004, not 443. So the iptables command still will not work for your particular packet example. Maybe this:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
answered Jun 6 at 14:07
Doug Smythies
6,24631426
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
The iptables u32 module offsets are referenced to the packet minus the ethernet wrapper (minus the source and destination MAC, 6 bytes each, and the ether type, 2 bytes. Therefore your wireshark offset of 46 needs to adjusted by 14, and should be 32.
Now, for a sanity check, find the type of service byte, which we know from the u32 area of the man pages for iptables-extensions is at offset 9 and we also know is 0x11 (17) for UDP. It is at byte 0x17 (23) of your wireshark screenshot. Counting from there, we also get 32 as the offset you should be using.
EDIT 1: Since the protocol is UDP, you also need to adjust that part of your iptables command. So:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
EDIT 2: In your example wireshark screen shot, the destination port is 5004, not 443. So the iptables command still will not work for your particular packet example. Maybe this:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
answered Jun 6 at 14:07
Doug Smythies
6,24631426
The iptables u32 module offsets are referenced to the packet minus the ethernet wrapper (minus the source and destination MAC, 6 bytes each, and the ether type, 2 bytes. Therefore your wireshark offset of 46 needs to adjusted by 14, and should be 32.
Now, for a sanity check, find the type of service byte, which we know from the u32 area of the man pages for iptables-extensions is at offset 9 and we also know is 0x11 (17) for UDP. It is at byte 0x17 (23) of your wireshark screenshot. Counting from there, we also get 32 as the offset you should be using.
EDIT 1: Since the protocol is UDP, you also need to adjust that part of your iptables command. So:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
EDIT 2: In your example wireshark screen shot, the destination port is 5004, not 443. So the iptables command still will not work for your particular packet example. Maybe this:
sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478
answered Jun 6 at 14:07
Doug Smythies
6,24631426
edited Jun 6 at 14:36
answered Jun 6 at 14:07
Doug Smythies
6,24631426
answered Jun 6 at 14:07
Doug Smythies
6,24631426
answered Jun 6 at 14:07
Doug Smythies
6,24631426
6,24631426
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
add a comment |Â
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
Thanks a lot Doug! That did helped me. It worked for udp! However, TCP packets still I am unable to match. I used 44 (+12 for TCP ) Am I missing something here?
– Mystic monk
Jun 6 at 15:40
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
I only learned about this stuff yesterday, but thought that STUN was only on UDP. I do not know about STUN on TCP. Maybe start a new question for TCP, and include a wireshark screenshot again, and include a reference to this question.
– Doug Smythies
Jun 6 at 15:52
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
Thats awesome. STUN can used on both tcp and udp. I need to collect wirehark logs. I will start a new question with wireshark log tomorrow.
– Mystic monk
Jun 6 at 16:10
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1043752%2fiptable-matching-rule-for-stun-turn-traffic%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Please edit your question and show us the entire iptables command line, and perhaps some overall context (i.e. you entire iptables rule set).
– Doug Smythies
Jun 5 at 14:30
How did you get the offset of 46? I calculate 24, but am finding it hard to figure out for certain.
– Doug Smythies
Jun 5 at 21:24
I got it from wireshark. I captured some wireshark STUN packets and all of them have the magic cookie at this location 46. Please find the screenshot attached from wireshark
– Mystic monk
Jun 6 at 5:57
Yes, but I do not think that the u32 module includes the ethernet wrapper bytes, so its offset needs to be different (try 32). It is late in my time zone, I'll work on this tomorrow. Thanks for the wireshark screen shot.
– Doug Smythies
Jun 6 at 6:29