libipq: problems changing destination port

libipq: problems changing destination port

[Lore]

Hi...
I'm trying to change the destination port of some
packets I receive through ipq.

I used the following chain:
  iptables -A OUTPUT -p "tcp" --dport 2022 -j QUEUE
and in the code I change the tcphdr->dest to 2021, do
a new checksum and verdict it with NF_ACCEPT.

The packet get's silently dropped and I don't know
why... 
I tried to change the data and everything worked but
when I tried to change the destination port nothing
went out of the box.

Can anyone help me?
thanks in advance
Lore


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: libipq: problems changing destination port

[Henrik Nordstrom]

On Sat, 29 Oct 2005, Lore wrote:

> and in the code I change the tcphdr->dest to 2021, do
> a new checksum and verdict it with NF_ACCEPT.
>
> The packet get's silently dropped and I don't know
> why...

Should work.. but make sure you get the TCP header checksum correct...

What does tcpdump say?

Also beware that conntrack won't be too happy if you modify the 
"connection details" like this. If you need conntrack loaded such mangling 
of the packets is better left to NAT..

Regards
Henrik

Re: libipq: problems changing destination port

[Lore]

First of all I have to apologize with Henrik because I
replied directly to him (I didn't noticed that Yahoo
replies only to the sender by default).

then it comes the repost:

Ok...
I do a new checksum... before changing the port I
checked that the checksum Algorithm was right by
comparing the system computed check with the one
computed by me.
Everything was right.

but in the moment I change the port the packet never
arrives.
Here's what comes out from TCPDump fetching on port
2026 the packets (originally for port 2022) that I
changed... from the first Ack on...:

root@morningmoon:/home/lore# tcpdump -i wlan0 dst port
2026 -vvv
tcpdump: listening on wlan0, link-type EN10MB
(Ethernet), capture size 96 bytes

16:27:50.094991 IP (tos 0x0, ttl  64, id 39743, offset
0, flags [DF], proto: TCP (6), length: 60)
192.168.0.4.32788 > geronte.cs.unibo.it.2026: S, cksum
0x5034 (correct), 2890202236:2890202236(0) win 5840
<mss 1460,sackOK,timestamp 14378819 0,nop,wscale 2>

16:27:50.119230 IP (tos 0x0, ttl  64, id 625, offset
0, flags [DF], proto: TCP (6), length: 40)
192.168.0.4.32788 > geronte.cs.unibo.it.2026: R, cksum
0x36fd (correct), 2890202237:2890202237(0) win 0

16:27:52.971108 IP (tos 0x0, ttl  64, id 39745, offset
0, flags [DF], proto: TCP (6), length: 60)
192.168.0.4.32788 > geronte.cs.unibo.it.2026: S, cksum
0x447b (correct), 2890202236:2890202236(0) win 5840
<mss 1460,sackOK,timestamp 14381820 0,nop,wscale 2>

16:27:52.995399 IP (tos 0x0, ttl  64, id 626, offset
0, flags [DF], proto: TCP (6), length: 40)
192.168.0.4.32788 > geronte.cs.unibo.it.2026: R, cksum
0x36fd (correct), 2890202237:2890202237(0) win 0

Any Idea?
Thanks a lot...
lore


--- Henrik Nordstrom <hno@marasystems.com> ha scritto:


> On Sat, 29 Oct 2005, Lore wrote:
> 
> > and in the code I change the tcphdr->dest to 2021,
> do
> > a new checksum and verdict it with NF_ACCEPT.
> >
> > The packet get's silently dropped and I don't know
> > why...
> 
> Should work.. but make sure you get the TCP header
> checksum correct...
> 
> What does tcpdump say?
> 
> Also beware that conntrack won't be too happy if you
> modify the 
> "connection details" like this. If you need
> conntrack loaded such mangling 
> of the packets is better left to NAT..
> 
> Regards
> Henrik
> 



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: libipq: problems changing destination port

[Henrik Nordstrom]

On Mon, 31 Oct 2005, Lore wrote:

> 16:27:50.094991 IP (tos 0x0, ttl  64, id 39743, offset
> 0, flags [DF], proto: TCP (6), length: 60)
> 192.168.0.4.32788 > geronte.cs.unibo.it.2026: S, cksum
> 0x5034 (correct), 2890202236:2890202236(0) win 5840
> <mss 1460,sackOK,timestamp 14378819 0,nop,wscale 2>
>
> 16:27:50.119230 IP (tos 0x0, ttl  64, id 625, offset
> 0, flags [DF], proto: TCP (6), length: 40)
> 192.168.0.4.32788 > geronte.cs.unibo.it.2026: R, cksum
> 0x36fd (correct), 2890202237:2890202237(0) win 0

Looks like you suceeded just fine, but failed to undo your rewrite on 
return traffic...

in the above return traffic seems missing. The picture I see is


192.168.0.4.32788 -> geronte.cs.unibo.it.2026 (2022) SYN

[not shown]
geronte.cs.unibo.it.2026 -> 192.168.0.4.32788 SYN+ACK

192.168.0.4.32788 -> geronte.cs.unibo.it.2026 RESET

Where I suspect the RESET is actually "I have no interest in talking to 
geronte.cs.unibo.it:2026, go agay please! I want to talk to 
geronte.cs.unibo.it:2022".


Does this make any sense to you?

Regards
Henrik

Re: libipq: problems changing destination port

[Lore]

This makes a lot of sense... and I think this will
save a lot of time to those who'll try to change the
port to an outgoing packet using LibIPQ.

the only way to make it work is another chain on
netfilters that passes every incoming packet to
userspace so that the port can be reverted to the
original one... so the sender is fooled and behaves
like it is directly connected to the server.

Thanks alot.

One more question:
I get every outgoing packet to userspace, get the ip
and port, connect to server to check if it has the
required services and daemon (the latter is part of my
project) and if both are true I redirect every
outgoing packet of that kind (port and IP) to a
predefined port. (if only the former is true, packets
are verdicted as NF_ACCEPT without any change)
As we ascertained, in the case service and daemon are
available, I have to change the port of all incoming
packet of that connection...
Do you think has better performance to add a new chain
for every port used (via execv) or to use a chain that
redirects every incoming packet to userspace, so that
I have to do a clean NF_ACCEPT to every incoming
connection that is not of my kind?

Thanks again and again...
Byez
lore

--- Henrik Nordstrom <hno@marasystems.com> ha scritto:


> On Mon, 31 Oct 2005, Lore wrote:
> 
> > 16:27:50.094991 IP (tos 0x0, ttl  64, id 39743,
> offset
> > 0, flags [DF], proto: TCP (6), length: 60)
> > 192.168.0.4.32788 > geronte.cs.unibo.it.2026: S,
> cksum
> > 0x5034 (correct), 2890202236:2890202236(0) win
> 5840
> > <mss 1460,sackOK,timestamp 14378819 0,nop,wscale
> 2>
> >
> > 16:27:50.119230 IP (tos 0x0, ttl  64, id 625,
> offset
> > 0, flags [DF], proto: TCP (6), length: 40)
> > 192.168.0.4.32788 > geronte.cs.unibo.it.2026: R,
> cksum
> > 0x36fd (correct), 2890202237:2890202237(0) win 0
> 
> Looks like you suceeded just fine, but failed to
> undo your rewrite on 
> return traffic...
> 
> in the above return traffic seems missing. The
> picture I see is
> 
> 
> 192.168.0.4.32788 -> geronte.cs.unibo.it.2026 (2022)
> SYN
> 
> [not shown]
> geronte.cs.unibo.it.2026 -> 192.168.0.4.32788
> SYN+ACK
> 
> 192.168.0.4.32788 -> geronte.cs.unibo.it.2026 RESET
> 
> Where I suspect the RESET is actually "I have no
> interest in talking to 
> geronte.cs.unibo.it:2026, go agay please! I want to
> talk to 
> geronte.cs.unibo.it:2022".
> 
> 
> Does this make any sense to you?
> 
> Regards
> Henrik
> 



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da
10MB 
http://mail.yahoo.it


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: libipq: problems changing destination port

[Henrik Nordstrom]

On Mon, 31 Oct 2005, Lore wrote:

> I get every outgoing packet to userspace, get the ip
> and port, connect to server to check if it has the
> required services and daemon (the latter is part of my
> project) and if both are true I redirect every
> outgoing packet of that kind (port and IP) to a
> predefined port. (if only the former is true, packets
> are verdicted as NF_ACCEPT without any change)

Ok.

> As we ascertained, in the case service and daemon are
> available, I have to change the port of all incoming
> packet of that connection...

Yes.

> Do you think has better performance to add a new chain
> for every port used (via execv) or to use a chain that
> redirects every incoming packet to userspace, so that
> I have to do a clean NF_ACCEPT to every incoming
> connection that is not of my kind?

I would just set a mark or similar, and then use the iptables nat to 
change the port... In mangle, just QUEUE the NEW traffic on the relevan 
port(s), in the userspace queue handler do all the checks and return the 
status of the check as nfmark, and in the nat table look for that mark to 
decice if the port needs to be changed.

But if you really want to do the port translation in userspace, then 
packets in both directions MUST be sent to QUEUE in iptables and the 
userspace would need to figure out what to do with the traffic. And you 
also MUST make sure that ip_conntrack is not activated (loaded) on the 
server.

Regards
Henrik

Re: libipq: problems changing destination port

[Martijn Lievaart]

Henrik Nordstrom zei:
> But if you really want to do the port translation in userspace, then
> packets in both directions MUST be sent to QUEUE in iptables and the
> userspace would need to figure out what to do with the traffic. And you
> also MUST make sure that ip_conntrack is not activated (loaded) on the
> server.

And you SHOULD translate all ICMP errors pertaining to this connection.

M4