Hello all,
I''ve got a problem to set up a configuration that shoud allow to route
packets that come in over a certain interface(s) IF1 that then should
go out to another interface IF2 but are addressed to the local address
of interface IF3. So only if packets for the address of interface IF3
come in over interface IF3 they should be locally accepted.
+------+
+---IF2/IP2-| HOST |-IF1/IP1---...LAN
. +------+
. |
. IF3/IP3
| |
| |
| |
+-Internet--...+
So, to accomplish the above scenario, I thought that it must be
possible to change the routing tables in such a way, that also the
local interfaces become routeable (is this anyway possible?).
To do this, I wanted to remove the local IP3 from table local:
ip route del local $IP3 dev lo src $IP3 table local
Now I just put for test reasons the same entry to another table:
ip route add local $IP3 dev lo src $IP3 table $ANOTHER_TABLE
ip rule add from any lookup $ANOTHER_TABLE
ip route flush cache
To my thought, the routing up to now should not have changed its
behaviour, but the following occurs: On the same host I could not
ping the IP3 any more and so also from any other host.
If I do a ip route get $IP3 the result looks like:
$IP3 via $DEFAULT_GW dev $DEFAULT_DEV src $DEFAULT_DEV_IP
cache mtu 1500 advmss 1460
If I''m right, this should tell me, that the kernel now no longer can
recognize its IP3?!
So, is it possible to do what I wanted to do or did I did something
not the right way?
I''m sorry if this question has been asked over and over again, but I
have googled and looked into the archives but haven''t found a solution
that fits my needs.
Best regards,
Christian
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Mon, 7 Jul 2003, Christian Stuellenberg wrote:> I''ve got a problem to set up a configuration that shoud allow to route > packets that come in over a certain interface(s) IF1 that then should > go out to another interface IF2 but are addressed to the local address > of interface IF3. So only if packets for the address of interface IF3 > come in over interface IF3 they should be locally accepted.Yes, you have a big problem. Starting from kernels 2.4 and above the routing requires valid source IPs for output routes. Even if you deliver locally the incoming traffic your servers can not generate reply if the src IP is not local IP. What I do not understand from your posts is what is the main goal? Also, what means "..."? Please, draw picture with all wires and all kinds of hardware involved: hubs, routers, subnets.> +------+ > +---IF2/IP2-| HOST |-IF1/IP1---...LAN > . +------+ > . | > . IF3/IP3 > | | > | | > | | > +-Internet--...+> If I''m right, this should tell me, that the kernel now no longer can > recognize its IP3?!Yes, the routing code does additionally lookup for IPs configured on interfaces (yet). The routing decisions are based on: - routing table lookups - IP lookups and checks> So, is it possible to do what I wanted to do or did I did something > not the right way?I''m not sure there is a right way. The task is not trivial. May be in some next kernel that allows the admin to create any route and not to apply any IP checks. You now do not have the full right to add any routes, that is the problem. You can not control the spoofing checks when saddr=local_IP, the preferred src IP must be local IP.> I''m sorry if this question has been asked over and over again, but I > have googled and looked into the archives but haven''t found a solution > that fits my needs. > > Best regards, > ChristianRegards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>>>> "Christian" == Christian Stüllenberg <christian_stuellenberg@web.de> writes: >>>>> "Julian" == Julian Anastasov <ja@ssi.bg> writes:Hello, Christian> I''ve got a problem to set up a configuration that shoud Christian> allow to route packets that come in over a certain Christian> interface(s) IF1 that then should go out to another Christian> interface IF2 but are addressed to the local address of Christian> interface IF3. So only if packets for the address of Christian> interface IF3 come in over interface IF3 they should be Christian> locally accepted. Julian> Yes, you have a big problem. Starting from kernels 2.4 Julian> and above the routing requires valid source IPs for output Julian> routes. Even if you deliver locally the incoming traffic Julian> your servers can not generate reply if the src IP is not Julian> local IP. What I do not understand from your posts is Julian> what is the main goal? Also, what means "..."? Please, Julian> draw picture with all wires and all kinds of hardware Julian> involved: hubs, routers, subnets. Ok, let me give you some more details. It''s even more complicated as my original picture. So the layout looks like: I N T +---------------+ ISPB-ptp--CISCOa.b.c.1/30--a.b.c.2/30+...............+a.b.c.62/28---GOOD E | . | | HOST ....+a.b.c.14/29---DMZ R | | | | N ISPA-ptp------PPPOE----------dynIP/32+.....masq......+192.168.0.1/24---MASQ +---------------+ E T No more hubs or switches envolved in the routing. All zones can only "talk" to each other over HOST. HOST has got several hardware interfaces. One to a zone called DMZ on networkinterface IF0 with IP0 and Submask NM0. Another to a zone called GOOD on IF1 with IP1/NM1. Then a zone called BAD on IF2 with IP2/NM2. Additionally a zone MASQ on IF3 with IP3/NM3 and another interface IF4. That''s the hardware layout. Zone GOOD, DMZ and BAD all have extern routeable IP-addresses. The zone BAD is quite small and in it is also a CISCO with a ptp connection to the ISP A. Zone MASQ is something of the form 192.168.0.0/24. At IF4 a pppoe-modem is attached so that over this pppoe line a dynamic (extern routable) IP address IP4 is attached over a ptp connection to the ISP B. So, for the zones GOOD and DMZ the default gateway is a.b.c.1 and for the zone MASQ the default gateway is the ptp-peer of the PPPOE connection. Everything that goes out over the PPPOE connection gets masqueraded. So far so good. If traffic from zone MASQ is addressed to one of the external internet addresses of one of the zone GOOD or DMZ, then it will currently get routed directly at HOST. It is intended, that this direct routing is not done, but instead ALL traffic from zone MASQ becomes masqueraded out over the dynamic PPP connection to the internet, comes back over the CISCO line to HOST, then gets routed to the extern destination IP (in zone GOOD or DMZ) and when the reply from there comes back again to HOST, it should get routed over the CISCO internet connection and then back over the dynamic PPP connection, demasqueraded, and at last delivered to the original source in zone MASQ. This works up to the point, where the reply comes back to HOST. Now I''m not able to tell HOST, that this reply should again routed out to the internet over the CISCO line and only demasqueraded if it comes in over the PPP connection (btw. the demasquerading does also not occur if the reply gets not routed; I assume, this is because the masquerding tables are waiting for a packet that comes in over the PPP connection and not on IF0 or IF1). Regards, Christian _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Thu, 17 Jul 2003, Christian Stuellenberg wrote:> If traffic from zone MASQ is addressed to one of the external internet > addresses of one of the zone GOOD or DMZ, then it will currently get > routed directly at HOST. It is intended, that this direct routing is > not done, but instead ALL traffic from zone MASQ becomes masqueraded > out over the dynamic PPP connection to the internet, comes back over > the CISCO line to HOST, then gets routed to the extern destination IP > (in zone GOOD or DMZ) and when the reply from there comes back again > to HOST, it should get routed over the CISCO internet connection and > then back over the dynamic PPP connection, demasqueraded, and at last > delivered to the original source in zone MASQ. > > This works up to the point, where the reply comes back to HOST. Now > I''m not able to tell HOST, that this reply should again routed out > to the internet over the CISCO line and only demasqueraded if it comes > in over the PPP connection (btw. the demasquerading does also not > occur if the reply gets not routed; I assume, this is because the > masquerding tables are waiting for a packet that comes in over the PPP > connection and not on IF0 or IF1).I think, I understand the setup. I''m still wondering what is the end goal. I can only speculate: Assumption 1. Hosts from GOOD want to see client from DynIP, not from a.b.c.62. The solution: use SNAT with saddr=DynIP when talking to GOOD because the default masquerade action is to use a.b.c.62 which is recommended from the routing. I assume GOOD and DMZ do not care how the packet with saddr=DynIP appeared as long as it looks as expected? 2. For some reason (even by introducing security problems) you want packets with saddr=DynIP to walk the external path and to reach GOOD. Is it needed? Is there a problem with the above solution in #1?> Regards, > ChristianRegards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>>>> "Christian" == Christian Stuellenberg <christian_stuellenberg@web.de> writes: >>>>> "Julian" == Julian Anastasov <ja@ssi.bg> writes:Hello, Christian> If traffic from zone MASQ is addressed to one of the Christian> external internet addresses of one of the zone GOOD or Christian> DMZ, then it will currently get routed directly at Christian> HOST. It is intended, that this direct routing is not Christian> done, but instead ALL traffic from zone MASQ becomes Christian> masqueraded out over the dynamic PPP connection to the Christian> internet, comes back over the CISCO line to HOST, then Christian> gets routed to the extern destination IP (in zone GOOD Christian> or DMZ) and when the reply from there comes back again Christian> to HOST, it should get routed over the CISCO internet Christian> connection and then back over the dynamic PPP Christian> connection, demasqueraded, and at last delivered to the Christian> original source in zone MASQ. Christian> This works up to the point, where the reply comes back Christian> to HOST. Now I''m not able to tell HOST, that this Christian> reply should again routed out to the internet over the Christian> CISCO line and only demasqueraded if it comes in over Christian> the PPP connection (btw. the demasquerading does also Christian> not occur if the reply gets not routed; I assume, this Christian> is because the masquerding tables are waiting for a Christian> packet that comes in over the PPP connection and not on Christian> IF0 or IF1). Julian> I think, I understand the setup. I''m still wondering Julian> what is the end goal. I can only speculate: Julian> Assumption 1. Hosts from GOOD want to see client from Julian> DynIP, not from a.b.c.62. The solution: use SNAT with Julian> saddr=DynIP when talking to GOOD because the default Julian> masquerade action is to use a.b.c.62 which is recommended Julian> from the routing. I assume GOOD and DMZ do not care how Julian> the packet with saddr=DynIP appeared as long as it looks Julian> as expected? Julian> 2. For some reason (even by introducing security problems) Julian> you want packets with saddr=DynIP to walk the external Julian> path and to reach GOOD. Is it needed? Is there a problem Julian> with the above solution in #1? I really want the long path, so that a client in zone MASQ can test, whether both uplinks to the internet work correctly. Not only to test the links, but also to provide a way, that a client in zone MASQ looks like any other (actually masqueraded) client in the world. We would''nt achieve that, if the routing from a client in zone MASQ takes directly place on HOST. Regards, Christian _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/