| View previous topic :: View next topic |
| Author |
Message |
xxlindsay
n00b
Joined: 17 Apr 2004
Posts: 3
|
 Posted: Tue Oct 05, 2004 11:16 am Post subject: iptables route target |
 |
|
I'd like to route a netblock to an ip which I have a route for but isn't locally connected. The route and ip route command isn't happy with setting a netblock to a gateway which isn't local. But, it looks like the iptables ROUTE target supports this. The route target is in the man pages but its not coded into the iptables ebuild from what I can tell. Does anyone know how to get the ROUTE target to work?
I'm running kernel 2.6.8.1 with iptables 1.2.11-r2 w/ the extensions flag.
Thanks for your help!
lindsay |
|
| Back to top |
|
 |
adaptr
Watchman
Joined: 06 Oct 2002
Posts: 6730
Location: Rotterdam, Netherlands
|
| Posted: Tue Oct 05, 2004 11:52 am Post subject: Re: iptables route target |
|
|
| xxlindsay wrote: | | I'd like to route a netblock to an ip which I have a route for but isn't locally connected. |
And you would accomplish this - how, exactly ?
Any locally routed traffic will need to use a local gateway; a gateway can in fact only be local - it cannot be on another subnet.
| xxlindsay wrote: | | The route and ip route command isn't happy with setting a netblock to a gateway which isn't local. |
Not only that, like I said: this is not even theoretically possible.
| xxlindsay wrote: | | But, it looks like the iptables ROUTE target supports this. |
It can't.
You may be confusing local routing with the use of a routing protocol such as RIP or IGMP - to use a routing protocol you have to actually own that netblock.
That is, if I'm following you correctly through all this. 
If I seem unhelpful - please report back with any more info, I'll be glad to comment some more.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
| Back to top |
|
|
xxlindsay
n00b
Joined: 17 Apr 2004
Posts: 3
|
| Posted: Tue Oct 05, 2004 12:52 pm Post subject: Re: iptables route target |
|
|
| adaptr wrote: | | xxlindsay wrote: | | I'd like to route a netblock to an ip which I have a route for but isn't locally connected. |
And you would accomplish this - how, exactly ?
Any locally routed traffic will need to use a local gateway; a gateway can in fact only be local - it cannot be on another subnet. |
ASCII art time:
| Code: |
Net A Rtr A Rtr B Rtr C Net C
----------- ----------- ----------
| |----------| |---------| |
----------- ----------- ----------
/24 /30 /30 /24
|
In the above picture, the router A,B,C are gentoo boxes connected via tunnels. Both rtr A and rtr C have routes for each other's vpn netblocks so that they can ping each other.
Here's where I'm trying to stretch it a little. I'd like to share a printer in Net C to Net A. Both Net C and Net A are NAT'd. Both Net C and Net A happen to use the same private ip netblocks.
So, I was going to try and assign Rtr A an extra ip out of Net A. When Rtr A sees this ip, it would rewrite the destination ip to that of the printer in Net C. It would also have to nat the ip to the tunnels and get the packet to Rtr C. Once the packet was on Rtr C, Rtr C could again nat the packet and deliver it to the printer. If we can get the packet to Rtr C, it should be ok for its destination ip has already been rewritten to the printers ip. On the way back, the two nat entries should get the packet to the correct source.
| adaptr wrote: |
| xxlindsay wrote: | | The route and ip route command isn't happy with setting a netblock to a gateway which isn't local. |
Not only that, like I said: this is not even theoretically possible.
|
Yeah, this might be too far fetched.  And maybe it would work if I ran ospf. And, maybe I need to setup a tunnel on top of these tunnels to encapsulate the packet.
Here's where I was going to try the iptables ROUTE target though. The man pages describe the ROUTE target to "explicitly override the core network stack's routing decision". I thought maybe we could match on the packet in Rtr A and route it straight to Rtr C since we have connectivity to Rtr C from Rtr A.
| adaptr wrote: |
| xxlindsay wrote: | | But, it looks like the iptables ROUTE target supports this. |
It can't.
You may be confusing local routing with the use of a routing protocol such as RIP or IGMP - to use a routing protocol you have to actually own that netblock.
That is, if I'm following you correctly through all this.
If I seem unhelpful - please report back with any more info, I'll be glad to comment some more. |
I would greatly appreciate any comments or ideas you have. |
|
| Back to top |
|
|
adaptr
Watchman
Joined: 06 Oct 2002
Posts: 6730
Location: Rotterdam, Netherlands
|
| Posted: Tue Oct 05, 2004 1:48 pm Post subject: Re: iptables route target |
|
|
| xxlindsay wrote: | ASCII art time:
| Code: |
Net A Rtr A Rtr B Rtr C Net C
----------- ----------- ----------
| |----------| |---------| |
----------- ----------- ----------
/24 /30 /30 /24
|
In the above picture, the router A,B,C are gentoo boxes connected via tunnels. Both rtr A and rtr C have routes for each other's vpn netblocks so that they can ping each other.
Here's where I'm trying to stretch it a little. I'd like to share a printer in Net C to Net A. Both Net C and Net A are NAT'd. Both Net C and Net A happen to use the same private ip netblocks. |
Ouch.
| xxlindsay wrote: | | So, I was going to try and assign Rtr A an extra ip out of Net A. |
Not useful - it already has one, remember ?
They are on the same subnet.
| xxlindsay wrote: | | When Rtr A sees this ip, it would rewrite the destination ip to that of the printer in Net C. It would also have to nat the ip to the tunnels and get the packet to Rtr C. Once the packet was on Rtr C, Rtr C could again nat the packet and deliver it to the printer. If we can get the packet to Rtr C, it should be ok for its destination ip has already been rewritten to the printers ip. On the way back, the two nat entries should get the packet to the correct source. |
Lot of ado - since the endpoints are on the same subnet (I wonder how you accomplished this in the first place) no routing takes place.
Yes, the traffic is tunneled through the VPN routers, but there is no layer 3 routing between Net A and Net C; there can't be, since they are - this is getting repetitive - on the same subnet.
| xxlindsay wrote: | | Yeah, this might be too far fetched. And maybe it would work if I ran ospf. And, maybe I need to setup a tunnel on top of these tunnels to encapsulate the packet. |
Another tunnel may or may not work - if you manage to let R-A make a direct tunnel to R-C you should in theory have direct connectivity.
Again - if these two endpoint nets are on the same subnet then routing is neither possible nor necessary - it should work as is.
I guess your ASCII art was still not clear enough...
One advice: assign different subnets to Net A and Net C, and all will be soo much simpler...
Not to mention the amount of problems you will get when there are address conflicts on the two nets.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
| Back to top |
|
|
xxlindsay
n00b
Joined: 17 Apr 2004
Posts: 3
|
| Posted: Tue Oct 05, 2004 3:43 pm Post subject: Re: iptables route target |
|
|
Let me start by saying thanks for you help so far. I'm very appreciative. I realize this thread is getting off topic and we can end it if you want.
I agree! The more I think it over, the more I think traffic between rtr A and rtr C would need encapsulated in a tunnel thus directly connected. I'll assume that for the rest of this thread.
| adaptr wrote: |
| xxlindsay wrote: | | So, I was going to try and assign Rtr A an extra ip out of Net A. |
Not useful - it already has one, remember ?
They are on the same subnet.
|
Maybe I can put some numbers on it to better explain the hack I'm trying.
Net A: 192.168.0.0/24
Net C: 192.168.0.0/24
Both Net A and Net C may and probably have overlapping ip allocations.
Printer = netc:192.168.0.10
Tunnel between Rtr A and Rtr C: 10.0.0.0/30
In Net A, I would assign or arp for an unused ip lets say neta:192.168.0.22 on rtr A. When rtr A sees traffic destined to 192.168.0.22, rtr A would dnat the packet to 192.168.0.10, snat the packet to the tunnel ip 10.0.0.1 and switch the packet to 10.0.0.2. If rtr C snat'd the packet to its lan ip 192.168.0.1 and delivered the packet to 192.168.0.10, the packet would have arrived at its destination and should? have a path home.
| adaptr wrote: |
Lot of ado - since the endpoints are on the same subnet (I wonder how you accomplished this in the first place) no routing takes place.
Yes, the traffic is tunneled through the VPN routers, but there is no layer 3 routing between Net A and Net C; there can't be, since they are - this is getting repetitive - on the same subnet.
Again - if these two endpoint nets are on the same subnet then routing is neither possible nor necessary - it should work as is.
One advice: assign different subnets to Net A and Net C, and all will be soo much simpler...
|
I could renumber but it would be neat if all the servers and code didn't need reconfigured on either end.
Another note, rtr A and rtr C are not gateways to the internet for either network. If I did renumber, we could simply route the netblocks at each other. But then, all the windows computers would need routes for the other netblock to point at rtr A and rtr C respectively. If the above solution were to work, neta:192.168.0.22 would simply look local to Net A and then iptables magic would take care of the rest.
But again, I don't want to take your time as I try my ip hacking. I didn't mean to drag you this far into it. Thanks again for your help! |
|
| Back to top |
|
|
adaptr
Watchman
Joined: 06 Oct 2002
Posts: 6730
Location: Rotterdam, Netherlands
|
| Posted: Wed Oct 06, 2004 2:45 pm Post subject: |
|
|
| Quote: | | I could renumber but it would be neat if all the servers and code didn't need reconfigured on either end. |
If you have code that needs to be changed for a simple IP change then you have hardcoded IP addresses in program code - a very big no-no.
And I will say it again: you will get IP address conflicts between those networks, which will be best avoided by assigning different subnets to the networks.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
