Re: UDPFROMTO and Proxy Problem
Raimund Sacherer wrote: Here is a more detailed description of our scenario [...] Thanks, it's a lot easier to undestand now. For a Proxy Packet the Packet-src_ipaddr is empty. It's the normal behaviour. The RADIUS server doesn't have knowledge about the network routes so it's the kernel who chooses the source address of the outgoing packet. In your scenario you are direct connected to the networks where your proxyserver resides so you don't need to use a default gateway to reach your servers. Indeed our previous scenario is different, but at least it shows that the udpfromto patch doesn't break the proxy functionality when the realm servers are connected on different network interfaces. My previously posted patch adds configuration items for the proxy.conf config file where you can define the ip_addr which should be used for each Realm. I would be glad if someone can confirm this as problem and my patch as the right solution ;-) It's just my opinion, but I'm not confident about putting elements related to the external network environnement inside the RADIUS server. But if you or the other people of the list can provide reasons it shoud be handled by radiusd, I'm interested to hear about it. +--+ +---+ | NAS/Roaming | (NAS/Roaming Partner may not be | 1 | | RadiusServer | part of our Network and can have their +---+ +--+ own Public/Private IP Networks) | | | +--+ | Our | +---| FireWall/| || IPSEC| || Tunnel | || Endpoint | |+--+ | | |+---+ | || 2 | +++ |+---+ | | |Clients which Clients with |comes from direct |IPSec Tunnels Internet Access | | | | | | | eth0:1 eth0 | 10.0.0.10 62.62.62.62 | | | |+--+ || Our |-eth1---[internal AdminLan] || RadiusServer | |+--+ | | | | +---+eth0:1 eth0 | | 3 | 10.0.0.10 62.62.62.62 | +---+ | | +-++ Now you gave us all the details about the problem in your setup, I'm thinking of a different approach: perhaps it could be easier to add a source NAT rule on the firewall rather than hacking the source IP inside radiusd. Did you try this ? Regards -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: UDPFROMTO and Proxy Problem
Nicolas Baradakis [EMAIL PROTECTED] wrote: Now you gave us all the details about the problem in your setup, I'm thinking of a different approach: perhaps it could be easier to add a source NAT rule on the firewall rather than hacking the source IP inside radiusd. Did you try this ? That would be the preferred approach. Routing loops generally cause problems, and the solution isn't to update the application to work around the problem. The solution should be to fix the routing loop in the routing code. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: UDPFROMTO and Proxy Problem
Hi Nicolas, Thomas! Here is a more detailed description of our scenario: +--+ +---+ | NAS/Roaming | (NAS/Roaming Partner may not be | 1 | | RadiusServer | part of our Network and can have their +---+ +--+ own Public/Private IP Networks) | | | +--+ | Our | +---| FireWall/| || IPSEC| || Tunnel | || Endpoint | |+--+ | | |+---+ | || 2 | +++ |+---+ | | |Clients which Clients with |comes from direct |IPSec Tunnels Internet Access | | | | | | | eth0:1 eth0 | 10.0.0.10 62.62.62.62 | | | |+--+ || Our |-eth1---[internal AdminLan] || RadiusServer | |+--+ | | | | +---+eth0:1 eth0 | | 3 | 10.0.0.10 62.62.62.62 | +---+ | | +-++ 1. Packet comes from NAS or from a Roaming Partner, either from internet or via IPSEC Tunnel, which terminates on Our Firewall. 2. The Firewall routes the Packet to our Radius Server. 3. The radius server auth/acct local realms and proxies all other realms to the appropriate foreign radius proxy/server back via Our Firewall. If the packet has to go to a partner which needs an IPSEC Tunnel it is proxied over eth0:1, otherwise over eth0. That's the point of our problem. In our case the default gateway points to the public ip_address of the internal interface of Our Firewall. For a Proxy Packet the Packet-src_ipaddr is empty. As the sendmsg function has no src_ipaddr it uses the default gateway as src_ipaddr for this packet. Therefore the IPSEC tunnel on Our Firewall discards the proxy packet because they expect the packet from 10.0.0.10 (LeftSide/RightSide IPSEC). Even if the IPSEC tunnel would allow our packets, the foreign radius server would silently discard the packet as it uses the wrong src_ipaddr. In your scenario you are direct connected to the networks where your proxyserver resides so you don't need to use a default gateway to reach your servers. My previously posted patch adds configuration items for the proxy.conf config file where you can define the ip_addr which should be used for each Realm. I would be glad if someone can confirm this as problem and my patch as the right solution ;-) For our 2.nd Problem i stated previously in this thread (that the above scenario is NOT working if eth0:1 is a physical interface) we will rebuild our test-scenario to post better debugging information. best regards Raimund Sacherer On Wed, 2004-10-20 at 16:34 +0200, Thomas MARCHESSEAU wrote: Hi Raimund, Nicolas and I did some test on proxy forwarding , we use this model : CLIENT 172.16.69.1 | vlan 69 | 172.16.69.3 (virtual ip handled by keepalived) | 172.16.69.2 (eth2) | +-+ | PROXY with udpfromto| | and bind_addr * | | ldflag = round_robin| +-+ | | eth0 eth3 192.168.7.241 10.17.1.243 | | | | +-vlan7-+ +-vlan1017--+ | | | | +--+ +--+ | Radius Srv | | Radius Srv | | 192.168.7.243| | 10.17.10.242 | +--+ +--+ We hope that it match with your goal . 1/ rad_recv:
Re: UDPFROMTO and Proxy Problem
Raimund Sacherer [EMAIL PROTECTED] wrote: My previously posted patch adds configuration items for the proxy.conf config file where you can define the ip_addr which should be used for each Realm. I would be glad if someone can confirm this as problem and my patch as the right solution ;-) The patch helps a bit. Please submit it to bugs.freeradius.org so it isn't lost. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: UDPFROMTO and Proxy Problem
Hi Raimund, Nicolas and I did some test on proxy forwarding , we use this model : CLIENT 172.16.69.1 | vlan 69 | 172.16.69.3 (virtual ip handled by keepalived) | 172.16.69.2 (eth2) | +-+ | PROXY with udpfromto| | and bind_addr * | | ldflag = round_robin| +-+ | | eth0 eth3 192.168.7.241 10.17.1.243 | | | | +-vlan7-+ +-vlan1017--+ | | | | +--+ +--+ | Radius Srv | | Radius Srv | | 192.168.7.243| | 10.17.10.242 | +--+ +--+ We hope that it match with your goal . 1/ rad_recv: Access-Request packet from host 172.16.69.1:32914, id=15, length=77 User-Name = [EMAIL PROTECTED] User-Password = 24r3iis NAS-IP-Address = 1.2.3.4 NAS-Port-Type = xDSL NAS-Port = 0 Sending Access-Request of id 0 to 192.168.7.243:1812 User-Name = [EMAIL PROTECTED] User-Password = 24r3iis NAS-IP-Address = 1.2.3.4 NAS-Port-Type = xDSL NAS-Port = 0 Proxy-State = 0x3135 rad_recv: Access-Accept packet from host 192.168.7.243:1812, id=0, length=103 Tunnel-Server-Endpoint:0 = 172.16.128.1 Tunnel-Assignment-Id:0 = 172.16.128.1 Service-Type = Framed-User Framed-Protocol = PPP Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IP Tunnel-Password:0 = secret Proxy-State = 0x3135 Login OK: [EMAIL PROTECTED]/24r3iis] (from client lodoss port 0) Sending Access-Accept of id 15 to 172.16.69.1:32914 Tunnel-Server-Endpoint:1 = 172.16.128.1 Tunnel-Assignment-Id:1 = 172.16.128.1 Service-Type = Framed-User Framed-Protocol = PPP Tunnel-Type:1 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Password:1 = secret 2/ rad_recv: Access-Request packet from host 172.16.69.1:32914, id=13, length=77 User-Name = [EMAIL PROTECTED] User-Password = 24r3iis NAS-IP-Address = 1.2.3.4 NAS-Port-Type = xDSL NAS-Port = 0 Sending Access-Request of id 0 to 10.17.1.11:1812 User-Name = [EMAIL PROTECTED] User-Password = 24r3iis NAS-IP-Address = 1.2.3.4 NAS-Port-Type = xDSL NAS-Port = 0 Proxy-State = 0x3133 rad_recv: Access-Accept packet from host 10.17.1.11:1812, id=0, length=103 Tunnel-Server-Endpoint:0 = 172.16.128.1 Tunnel-Assignment-Id:0 = 172.16.128.1 Service-Type = Framed-User Framed-Protocol = PPP Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IP Tunnel-Password:0 = secret Proxy-State = 0x3133 Login OK: [EMAIL PROTECTED]/24r3iis] (from client lodoss port 0) Sending Access-Accept of id 13 to 172.16.69.1:32914 Tunnel-Server-Endpoint:1 = 172.16.128.1 Tunnel-Assignment-Id:1 = 172.16.128.1 Service-Type = Framed-User Framed-Protocol = PPP Tunnel-Type:1 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Password:1 = secret As you can see above , the proxy receives response on both Interfaces . we dont find any problems with this kind of setup , you might check again if its really a problem with Freeradius or your network config [ iptables , routing problems, tcpwrapper ... ] We re using freeradius 1.0.1 + udpfromto patch, on debian sid + 2.4.26-grsec Regards Nicolas , Thomas . Raimund Sacherer wrote: Here is our Scenario which is working now: Some Partners depend on an IPSec tunnel. +--+ | Our | | RadiusServer | +--+ | | eth0:1 eth0 10.0.0.10 62.62.62.62 | | | | | | | | +-IPSec Tunnel--+ +-Internet--+ | | | | +--+
Re: UDPFROMTO and Proxy Problem
Raimund Sacherer [EMAIL PROTECTED] wrote: There where two problems with proxying, first, i listen to 2 ip addresses, if those where on different interfaces (eth0/eth1) it is not working, the problem is, the packet is sent to the roamingpartner, but the response is not recognized by freeradius (where a local test with netcat is recognized), but i can see it clearly with tcpdump. ... Please submit the patch to bugs.freeradius.org. That way it won't get forgotten. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: UDPFROMTO and Proxy Problem
Here is our Scenario which is working now:
Some Partners depend on an IPSec tunnel.
+--+
| Our |
| RadiusServer |
+--+
| |
eth0:1 eth0
10.0.0.10 62.62.62.62
| |
| |
| |
| |
+-IPSec Tunnel--+ +-Internet--+
| |
| |
+--+ +--+
| Other Radius Srv | | Other Radius Srv |
| from RaomPartner | | from RaomPartner |
+--+ +--+
If eth0:1 is another physical device (e.g. eth1) then it is NOT working.
Netstat -uan displays that the radius server is listening on all
(interfaces/ip-addresses) on port 1814.
Sending an request-package to our Roaming Partner is working (from the
correct IP also, but the respond from the Roaming Partner is not
recognized by our Radius Server but tcpdump shows that the Roaming
Partner sends an Respond (either Access Reject or Access Accept) and
that it's incoming on our interface (eth1).
If i move the IP from eth1 to eth0:1 as an alias, all is working again.
Strange is, if i locally connect with netcat to eth1 udp port 1814, our
Radius Server IS answering.
I do not really know where the problem exists, it works with IPAliases,
but i would feel much more secure if we can find a working solution for
eth1 also.
Here is an example from our configuration:
--- SNIP radiusd.conf---
#bind_address = *
#bind_address = 10.0.0.10
listen {
ipaddr = 10.0.0.10
type=auth
}
listen {
ipaddr = 10.0.0.10
type=acct
}
listen {
ipaddr = 62.62.62.62
type=auth
}
listen {
ipaddr = 62.62.62.62
type=acct
}
--- SNIP ---
--- SNIP proxy.conf---
proxy server {
synchronous = no
retry_delay = 10
retry_count = 6
dead_time = 0
default_fallback = no
post_proxy_authorize = no
proxyip = 62.62.62.62
}
realm veryFrightenedRoamingPartner {
type= radius
authhost= 172.172.172.172:1812
accthost= 172.172.172.172:1813
proxyip = 10.10.10.10
secret = SECRET
}
--- SNIP ---
On Tue, 2004-10-12 at 16:47 +0200, Raimund Sacherer wrote:
Hi,
i compiled freeradius (1.0.1) with the UDPFROMTO configure option and i
applied the patch from nicolas
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg09417.html)
and now receiving/sending local auth/acct packets with more than one ip
address works as expected.
There where two problems with proxying, first, i listen to 2 ip
addresses, if those where on different interfaces (eth0/eth1) it is not
working, the problem is, the packet is sent to the roamingpartner, but
the response is not recognized by freeradius (where a local test with
netcat is recognized), but i can see it clearly with tcpdump.
It works well if these 2 ip addresses are on the same interface (with
ip-alias).
The second problem with proxying is that it used the interface which was
defined to send data to the standard gateway as the src-ip address for
sending proxy-packets.
That was a problem for our scenario, as we have roamingpartners which
are listening for our packets on the first ip and others on the other,
therefore i patched freeradius to except in the realm-configuration
another parameter which tells the proxy_send method which src-ip it
should use to send the data, this is working and solved this second
problem, i have the patch attached and would be happy if it made it's
way into the source.
Technical Detail about the Patch:
1. Add Proxy IP Address to CONF_PARSER proxy_config[], MAIN_CONFIG_T and
into the REALM struct.
2. In generate_realms check if there is a proxy_ip set for this realm or
a global (mainconfig.proxy_ipaddr) one. If so, apply it.
3. In proxy_send check if in the REALM is an IP address set, if so, set
it in request-proxy-src_ipaddr so we have a src IP.
--- snip ---
--- freeradius-1.0.0-pre2/src/include/radiusd.h 2004-10-04
10:27:37.0 +0200
+++ /tmp/freeradius-1.0.0-pre2-ewave/src/include/radiusd.h2004-10-12
12:45:24.353286104 +0200
@@ -124,6 +124,7 @@
charserver[64];
characct_server[64];
uint32_tipaddr; /* authentication */
+ uint32_tproxy_ipaddr; /* proxy via interface, rsacherer */
uint32_tacct_ipaddr;
u_char secret[32];
time_t last_reply; /* last time we saw a packet */
@@ -194,6 +195,7 @@
int
