Todor Genov wrote:
Hi everyone,
I may have found a routing bug relating to GRE tunnels. Could somebody
try and replicate this?
As per the setup below GRE-encapsulated traffic to 194.31.254.148
should be going out via tun1, but a tcpdump shows the traffic leaving
via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148
goes out via tun1 as expected.
Configuration:
FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008
tun0 - PPPoE connection to ISP
tun1 - vpn connection to office PIX (via vpnc)
gre0 - GRE tunnel to machine sitting behind the PIX
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00
Opened by PID 509
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40
Opened by PID 984
Point to point interfaces really don't have netmasks.
Otherwise it wouldn't be "Point to Point", it would be
"multicast" like ethernet.
There is really only one address at this end or the other end.
If you want to say that there is a network at the other end
then you really need to set a route for it.
but it applies equally to all three of these p2p links.
so, add a route:
route add 92.168.254.0/24 92.168.254.1
gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1476
tunnel inet 194.31.137.70 --> 194.31.154.148
inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00
Routing table:
Destination Gateway Flags Refs Use Netif Expire
default 41.142.82.1 UGS 1 1365 tun0
41.142.82.1 41.142.82.37 UGH 1 0 tun0
192.168.254.1 192.168.254.2 UH 0 3 gre0
194.31.137.64 194.31.137.70 UH 1 0 tun1
194.31.154.148 194.31.137.64 UGS 0 0 tun1
GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed
via tun0
Why do you think you need -S? routing takes into account only the
destination..
[EMAIL PROTECTED] ~]# tcpdump -ni tun0 proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP
192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777,
length 64
ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is
routed via tun1
[EMAIL PROTECTED] ~]# tcpdump -ni tun1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes
23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id
10757, seq 14, length 64
23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id
10757, seq 14, length 64
However, if I add a /24 route for the GRE endpoint subnet, instead of a
/32 to the host:
194.31.154.0/24 194.31.137.64 UGS 0 0 tun1
and then bring up the GRE tunnel, everything works as expected and GRE
traffic exits via tun1.
yes.. that is as expected..
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
