Two routerboards on the same physical lan and two addresses on client nic

[ZeroByte]

@ik3umt

Thanks,
I was reading for different type of tunnels just now…

So , with just the simple IPSEC, is a new policy needed for every new subnet I need to manage ??

Then you suggest the use of GRE over IPSEC support, so a tunnel interface is added and I can manage all my routes upon , isn’t it ?

Yes to all points. It sounds like you understand what’s going on.
You’ll find that to be so much easier to manage.

Simple IPSec is just a set of rules to scramble packets with a specific set of source/destination pairs. The scrambled packet is then forwarded to a pre-determined address, where the packet is de-scrambled and continues to be forwarded. There is no “IPSec” interface - that was the thing that completely confused me about IPSec for quite a long time. (and continues to annoy me to this day)

[ik3umt]

Yeah…up and running easily with gre over ipsec…
But I suppose I need a manual static route for any subnet to manage through the other end of the tunnel (at least I had to do so…)

[rmmccann]

@ik3umt

Yeah…up and running easily with gre over ipsec…
But I suppose I need a manual static route for any subnet to manage through the other end of the tunnel (at least I had to do so…)

GRE is just the tunnel. You either do like you did with static routes from there, or use a routing protocol like RIP or OSPF.

[ZeroByte]

And if you use RIP, then go sit in the corner until you’re sorry for what you’ve done!

j/k RIP does have its place - a very unique, limited, specialized place…

[rmmccann]

@ZeroByte

And if you use RIP, then go sit in the corner until you’re sorry for what you’ve done!

j/k RIP does have its place - a very unique, limited, specialized place…

Haha. I use it internally because my network isn’t big enough nor has enough routers for me to justify OSPF. It was dead simple to implement and with some carefully planned route prefixes, works perfect for my needs (which was just a means of redistributing static routes).

[ZeroByte]

@rmmccann

Haha. I use it internally because my network isn’t big enough nor has enough routers for me to justify OSPF. It was dead simple to implement and with some carefully planned route prefixes, works perfect for my needs (which was just a means of redistributing static routes).

Yep. RIP is just fine on networks that are fairly small and fairly stable.

[ik3umt]

Just implemented RIP…amazing…

Another problem (i hope the last one..)

DSL Router has a static route 192.168.1.0/24 via 192.168.2.1
From Routerboard A terminal, I can ping the 20.0.0.0 network
From PC1 I CANNOT ping 20.0.0.0 network despite the 20.0.0.0 route is on the route list (gw 10.0.0.2 reachable gre-tunnel1) learned via RIP

I have to manually add a static route 10.0.0.0/30 via 192.168.2.1 into DSL router to allow PC1 to ping 20.0.0.0 network
Is there a way to avoid this ?? (real DSLrouter is managed by ISP provider who don’t want to modify config.)

[ZeroByte]

@ik3umt

I have to manually add a static route 10.0.0.0/30 via 192.168.2.1 into DSL router to allow PC1 to ping 20.0.0.0 network
Is there a way to avoid this ?? (real DSLrouter is managed by ISP provider who don’t want to modify config.)

DSL Router needs to participate in RIP also.
The reason you can ping from terminal of A, but not PC1 is that when you ping from A, the source IP will be the interface the pings leave the router by - which is 10.0.0.1, and as you stated, you’ve added a route for that. DSL router needs a static route to PC1 - I’m not sure if the diagram has a typo - 192.168.5.1? shouldn’t that be 192.168.1.5?

Either/or - the DSL router needs to know that PC1’s IP lies beyond router B.

[ik3umt]

Just contacted ISP , it says RIPv2 should be enabled
This is ok as I just tried to enable RIP in my dummy DSL router and all is reachable now !!!
(yes, pc1 address is 192.168.1.5… )

Thank you