Date: Tue, 11 May 2010 17:30:08 GMT From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= <kes-kes@yandex.ru> To: freebsd-net@FreeBSD.org Subject: Re: kern/146394: [vlan] IP source address for outgoing connections Message-ID: <201005111730.o4BHU8eL096445@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/146394; it has been noted by GNATS.
From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= <kes-kes@yandex.ru>
To: bug-followup@FreeBSD.org, kes-kes@yandex.ru
Cc:
Subject: Re: kern/146394: [vlan] IP source address for outgoing connections
Date: Tue, 11 May 2010 20:05:36 +0300
jFo> Synopsis: [vlan] IP source address for outgoing connections
jFo> State-Changed-From-To: open->feedback
jFo> State-Changed-By: julian
jFo> State-Changed-When: Sat May 8 09:47:30 PDT 2010
jFo> State-Changed-Why:
jFo> The behaviour you quote as a bug is expected and useful and I don't think it is a bug.
jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the
jFo> outgoing packet will leave. If you do not do this there is no guarantee that the
jFo> client will be able to get to the responding address as it may be on a differnet network.
jFo> Anyhow there are ways to do what you want.
jFo> firstly: what you are talking about will ONLY happen if you do not bind the
jFo> socke to an address, so looking in the config file and binding it will
jFo> fix it. Most programs have an option to do this. I had to do this yesterday with named.
jFo> (though I didn't find such an option in ntpd).
jFo> You need to look at what is going on using sockstat and netstat -aAn
jFo> any socket that has a local address of "*" will have this behaviour.
jFo> If you can't do this then you can use the jail command to force a program that
jFo> does not support binding to be bound.
jFo> Put it in a jail that has the same root as the rest of the system
jFo> but has a forced IP address of that you want.
jFo> Let me know if this solved your problem an dwe can close the bug.
Actually your suggestion (jail), not mine (setip tool) will not resolve the problem.
192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(KERNEL)-(rl1)(192.168.1.1/24)<----192.168.1.0/24
now if 192.168.0.7 will enable connection to 192.168.1.1:80 it will get answer from 192.168.0.1:80
this seems like spoofing =( and some services like mpd<-->radiusd in this
situations will fail: response is from untrusted source and md5 chechsum mismatch
I agree with you, that I can force daemon to bind to some IP, but in
this situation bind *.1812 (or any other service) seems useless despite on in 99% of cases it
works fine.
jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the
jFo> outgoing packet will leave. If you do not do this there is no guarantee that the
jFo> client will be able to get to the responding address as it may be on a differnet network.
This is ok, for packets when connection is negitiated from router to client,
but in situations when client do connection to 192.168.1.1 it must get
response from 192.168.1.1 and not from any other machine. Do you agree?
Router do connections to lan:
So connections from ROUTER to 192.168.0.0/24 will have 192.168.0.1 IP in packets as source address
So connections from ROUTER to 192.168.1.0/24 will have 192.168.1.1 IP in packets as source address
Router is response to lan:
So in connections from CLIENT to router. Router must response from that IP to which client have established connection
Case 1:
query: 192.168.0.7 -> 192.168.0.1
response: 192.168.0.1 -> 192.168.0.7
Case 2:
query: 192.168.0.7 -> 192.168.1.1
response: 192.168.1.1 -> 192.168.0.7
So if client can establish connection to IP from other net he MUST get response from that IP!
If client is not allowed to establish connection to IP from other net it MUST not get any response packet at all
(Except maybe icmp: host is unreachable or etc.)
bring to notice: if client can establish connection to IP from other net it CAN get response from that IP
so router MUST resonse from that IP to which client establish connection
and ONLY if router establish connection itself it MUST, as you said:
jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave
Look at this example:
R.E.A.L/32
(lo0)
192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(ROUTER0)-(rl1)(192.168.1.1/24)
| |
| |
192.168.0.7/24 192.168.1.7/24
(rl1) (rl0)
(ROUTER1) (ROUTER2)
(rl0) (rl1)
SOME.REAL.IP.1 SOME.REAL.IP.2
\ /
\-------------------- CLIENT --------------------------/
192.168.0.1 is allowed on ROUTER1 and is nated to SOME.REAL.IP.1
192.168.1.1 is allowed on ROUTER2 and is nated to SOME.REAL.IP.2
on ROUTER1:
route add R.E.A.L/32 192.168.0.1
on ROUTER2:
route add R.E.A.L/32 192.168.1.1
on ROUTER0:
there two default gateways with equal costs
0/0 192.168.0.7
0/0 192.168.1.7
Now as you said:
jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave
if CLIENT establish connection to R.E.A.L it will get
50% packet response from SOME.REAL.IP.1 and 50% from SOME.REAL.IP.2 %-)
also because of NAT on ROUTER1 and ROUTER2 we will have resource leak
tcpdump on CLIENT willshow:
CLIENT -> R.E.A.L
SOME.REAL.IP.1 -> CLIENT
CLIENT -> R.E.A.L
SOME.REAL.IP.2 -> CLIENT
Bring notice that that response packet have different IPs! from
resource we are establish connection. In 99% this work, 1% -- WILL NOT!
As I have said:
>>So if client can establish connection to IP from other net he MUST get response from that IP!
in this situations everithing is expected:
1. No resource leak on ROUTER1 and ROUTER2 and maybe ROUTER3...
2. tcpdump on client:
CLIENT -> R.E.A.L
R.E.A.L -> CLIENT
CLIENT -> R.E.A.L
R.E.A.L -> CLIENT
Another case: Router establish connection to CLIENT
This is the case your rule MUST apply:
jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave
jFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=146394
--
Eugen Konkov mailto:kes-kes@yandex.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201005111730.o4BHU8eL096445>