On Sat, 6 Dec 2003, Darryl Miles wrote:I understand better what you are asking. I take it there is no NAT involved at all, these networks are ISP sites with fully routed Internet address space, then maybe you are looking for a policy route so that any traffic coming from the 172.26.3.0/24 subnet it routed down the tunnel. Since this address space is only used internally on the ISPs corporate network and should never escape into NetC.
petrch@xxxxxxxxx wrote:
I have this:Normally you'd configure the tunnel endpoint routers at both sites to
publicIP(server)-netA--internet(netC)--netB--172.26.3.0/24
I have tunnel between netA and netB. The tunnel is for manage some network devices what are using private IP from network 172.26.3.0/24. Now if I ping from publicIP (it could be server with nagios). Echo request packet is routed through tunnel and reaches 172.26.3.1(device) but echo reply is routed via default route on netB gateway and NATed out to internet.
Question: Could I somehow discover that echo request traveled
by tunnel so reply should take same way?
have recipriocal routing entries for each others subnet. Also configure
Yes, I've this done for nonpublic networks (more exactly for 172.26.0.0/16 which one we are using for network management). But netA is small ISP with about 1000 subscribers and we are not AS right now. You're probably right, that I could simply add one route for each our assigned C network, but than I have to reconfigure each tunnel after each change.
I'd also advise / confirm you have an egress firewall entry facing NetC to drop any packets not confirming to NetB's public address space, this would also be your last barrier to stopping corporate management information leaking onto the Internet.
On the NetB router:
ip route add table 4 default dev tunl0 ip rule add from 172.26.3.0/24 table 4 ip route flush cache
Amend accordingly.
One solution maybe to use OSPF through the tunnel. Providing you can control the routes each end advertises and accepts, you only want to announce those routes down the tunnel that you want to be used down the tunnel and you only want the PrivateIP hosts of NetB to be affected by those routes, this last point sounds like a headache with OSPF.I could simply use OSPF and set it on netB gw (we are using OSPF on netA), but than all traffic to netA will go throught tunnel, what is not exactly what I need.
One more difficulty is, that in netB are couple of clients onYou have to creativly work out a set of prefixes that cover all the IPs you want (172.26.3.240/28), Does anyone know of a tool to do this job ?
172.26.3.0/24 (clients has addresses from .2 up and devices goes
from 254 down).
Just out of interest what do these clients do on these IPs since they can't use them on the Internet (NetC) anyway, what need do they have to have them routable past your tunnel box / default gateway to NetC ? An egress Firewall on the tunnel interface might elect to return these with ICMP.
This was only with regards to mixing your PrivateIP addr space of corporate network with your customers networks.As I'm writing now, I'm starting to understand your advice like this: "You screwed up you address plan. If you are doing things right way, you could not have this problem at all."
Ah this is what I just put above with the config. You can put in multiple policy routing rules in, however depending on how much throughput this router sees it maybe advisable to re-work your Private address space as you suggest so a single check is needed per routing decision, maybe this point is moot with the routing cache anyway.So one way is to simply move devices on netB to their own network 172.26.x.0/24 and all traffic from this network route to tunnel.
Is there any other way, how to "autoconfigure" routing through tunnel?
IP Datagrams can record enroute information like this, think of it as Corporate policy routing, lookup DiffServ/TOS/DSMASK (on google), however once a datagram has gotten to its host some of this information may get lost, the only way it to test yourself with the hosts concerned and tcpdump.
This method means re-assigning the Precedence field of the IP header, maybe all networking stacks written honour this field and re-use it in the reply packet. I've never tried this so I can't be too sure, the IP specs may say a stack must do this, but in reality its not a well used feature, so using it between participating routers on a per datagram basis is one thing (ala DiffServ) and getting it echoed through hosts and back to the routers is another.
So maybe you can mark the IP header of the packet when it leaves the tunnel endpoint so that the host (hopefully) also keeps this marking in the reply packet coming back the other way. Providing your routing on the LAN is setup so that the tunnel endpoint gets to see all the traffic to vet it for this marking or not, before selecting it for the Public Internet (NetC) or to enter the tunnel. When it enters the tunnel you may need to strip this marking off, since its a locally applied policy that only the site of NetB knows about, it seems correct to undo it when it leaves this domain.
One solution for this would look like using ipchains rule to select and mark the packet when it arrive, then setup a policy route to use this marking to select it for routing via the tunnel. Maybe the policy routing rules allow isolation and selection of the precedence field of the packet.
Darryl
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
