routing issue

ioni

ioni

Hello,

I have set up a gre tunnel to connect to our private network which works fine. The primary interface has a secondary IP assigned of 10.9.16.1 (as alias0) and I have set up a route of 10.0.0.0/8 to gre0 tunnel.
Code: 
10.0.0.0/8         192.168.20.6       UGS         0        2   gre0
When I try to access or ping a host inside the network, the packets are sent with the source of the IP of the gre tunnel.

[cmd=]ping -S 10.9.16.1 10.9.7.102[/cmd] works fine.

What's the FreeBSD way of fixing this issue? In Linux IP route has an option src that can be used but the route command from FreeBSD doesn't support it.
 
Can you post your $ ifconfig -a? I don't understand from your description but it sounds like you are using the 10.0.0.0/8 route into the gre0 tunnel and maybe using 10.9.0.0/16 on your internal network. Don't be surprised by it using that route you specify. You may be able to override it for your internal network by having an 10.9.0.0/16 route pointing inside but that is an ugly workaround.
 
Here is the output requested:
Code: 
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
	ether 00:21:85:62:4c:06
	inet IP netmask 0xffffffe0 broadcast BROACASTIP
	inet6 fe80::221:85ff:fe62:4c06%re0 prefixlen 64 scopeid 0x1 
	inet6 IpV6 prefixlen 64 
	inet 10.9.16.1 netmask 0xffffff00 broadcast 10.9.16.255
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 
	inet 127.0.0.1 netmask 0xff000000 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1476
	description: private
	tunnel inet LOCALIP --> REMOTE IP
	inet6 fe80::221:85ff:fe62:4c06%gre0 prefixlen 64 tentative scopeid 0x9 
	inet 192.168.20.5 --> 192.168.20.6 netmask 0xfffffffc 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Code: 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            GW           UGS         1 28259218    re0
10.0.0.0/8         192.168.20.6       UGS         0       10   gre0
10.9.16.0/24       link#1             U           0        0    re0
10.9.16.1          link#1             UHS         0        0    lo0

I can access without any problem 10.9.6.1 from my internal network but cannot access internal network without changing source of packets.

Code: 
 ping -S 10.9.16.1 10.9.7.102
PING 10.9.7.102 (10.9.7.102) from 10.9.16.1: 56 data bytes
64 bytes from 10.9.7.102: icmp_seq=0 ttl=63 time=37.736 ms
 
So what's the problem exactly?

The source of ping will be the IP address of outgoing interface closest to the destination host. In this case it is the source of the tunnel since that host is reachable trough the tunnel. When you are pinging behind the tunnel, the host that receives the packet doesn't know how to return it.

This shouldn't matter as hosts behind either side of the tunnel don't really know nor care about tunnel or its addressing.
 
I want to be able to access hosts behind the tunnel having 10.0.0.0/8. Right now I cannot. What's the proper solution in FreeBSD for this matter?
 
@ioni, the issue is that you are overlapping your gre0 static route on top of networks you already have internally. From what you have posted you have 10.9.16.0/24 directly connected on re0 with 10.9.7.0/24? further internal on re0. Since 10.0.0.0/8 is more specific than the default it will take precedent.

The ideal fix would be to not have this overlap and potential confusion. If the other end of gre0 is all in 10.10.0.0/16 then change your gre0 route to reflect that. At that point, the overlap is gone and your default route on re0 would apply sending your packets the right way. I would echo that a network drawing would be helpful in sorting out what routes need to go where.
 
Last edited by a moderator:
No, 10.9.7.0/24 is connected to gre0, hence the 10.0.0.0/8 route to 192.168.20.6 (the end of the tunnel).
 
You must log in or register to reply here.
Back
Top