* Re: [LARTC] track tunnel connections
2003-12-05 20:30 [LARTC] track tunnel connections petrch
2003-12-06 2:06 ` Darryl Miles
@ 2003-12-06 8:30 ` petrch
2003-12-06 18:29 ` Darryl Miles
2 siblings, 0 replies; 4+ messages in thread
From: petrch @ 2003-12-06 8:30 UTC (permalink / raw)
To: lartc
On Sat, 6 Dec 2003, Darryl Miles wrote:
> petrch@regnet.cz wrote:
>
> >I have this:
> >
> >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?
> >
> >
>
> What tunneling technology are you using (IPIP, GRE, VPN
> (ESP/AH/PPTP/...) ) ?
It's GRE.
> Normally you'd configure the tunnel endpoint routers at both sites to
>
> 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 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 on
172.26.3.0/24 (clients has addresses from .2 up and devices goes
from 254 down).
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."
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?
> on the endpoint hosts a black hole routing entry with a higher metric
> than the tunnel, so that "Network Unreachables" are correctly returned
Ok. thanks. I forgot to do this.
> So I ask: Does your network topology really need to be able to discover
I'm not sure. Probably I can at least redesign netB and reconfigure
devices there. netB is 80km from here and maybe I'm only afraid that
I will have to leave my neat office and drive there.
>
>
> Darryl
>
Petr Chloupek
petrch@regnet.cz
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] track tunnel connections
2003-12-05 20:30 [LARTC] track tunnel connections petrch
2003-12-06 2:06 ` Darryl Miles
2003-12-06 8:30 ` petrch
@ 2003-12-06 18:29 ` Darryl Miles
2 siblings, 0 replies; 4+ messages in thread
From: Darryl Miles @ 2003-12-06 18:29 UTC (permalink / raw)
To: lartc
petrch@regnet.cz wrote:
>On Sat, 6 Dec 2003, Darryl Miles wrote:
>
>
>
>>petrch@regnet.cz wrote:
>>
>>
>>
>>>I have this:
>>>
>>>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?
>>>
>>>
>>Normally you'd configure the tunnel endpoint routers at both sites to
>>
>>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 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.
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.
>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 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.
>One more difficulty is, that in netB are couple of clients on
>172.26.3.0/24 (clients has addresses from .2 up and devices goes
>from 254 down).
>
>
You 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 ?
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.
>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."
>
This was only with regards to mixing your PrivateIP addr space of
corporate network with your customers networks.
>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?
>
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.
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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread