This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing issue - not sure how to solve...experts?

Ok here is the problem.... running ASL 4.026.

One interface, say eth1, is on the 10.10.x.x/16 network. Now I have a need to setup a site to site tunnel, where the remote network is 10.10.1.x/24. 

After a reboot, pings and such work, but once the eth1 interface is used, pings over the tunnel don't work anymore. Packet counters for the tunnel do not increase, and traceroutes end at the firewall.

I *think* the packets are trying to go out eth1, instead of the tunnel.

Anyone have any advice? 

EDITED: There is only one host I need to reach on the 10.10.x.x network, which comes in at 10.10.1.2 . I thought about doing a hostbased routing entry to have only traffic for that host go out that interface.. doesn't work, since the interface causes an automatic route to be brought up point 10.10.0.0/16 out eth1.

I want all other traffic for 10.10.1.x to go over the vpn.. 


This thread was automatically locked due to age.
  • I don't know if this can work.

    Possible options (guessing):
    NAT one of the networks?

    Use bridging (ASL 6)?
    (assuming bridging and VPNs can get along)

    Barry
  • [ QUOTE ]
    One interface, say eth1, is on the 10.10.x.x/16 network. Now I have a need to setup a site to site tunnel, where the remote network is 10.10.1.x/24.

    [/ QUOTE ]It appears that your remote network's address range (10.10.1.x/24) is inside your local networks address range (10.10.x.x/16). For routing to work, you can not use the same address ranges on different subnets. I would suggest changing the address range used for one of your subnets to something else. Unless you really need subnet addressing ranges big enough to hold 65,000 or more machines, your best bet is to stay away from using the 10.x.x.x addressing range. Stick with the 192.168.x.x private addressing range for small subnets with less than 253 machines. When defining private subnets, avoid using the very common ones, with a "0" or a "1" in the third octet. Use at least a two digit number instead.

    Routing and VPN problems caused by using very common private net number choices for several different subnets, thus creating routing conflicts,  are easily avoided if you get a bit more creative about your net numbering. Keep in mind that when defining a class "C" subnet, you have 65,536 different net numbers to choose from in the 10.x.x.x address range, and 256 different ones to choose from in the 192.168.x.x address range. With so many different ones available, it amazes me that so many people keep picking the same ones over and over, by using "0" or "1" in the third octet.