Questions[gre](server)

With iproute2 on Linux, gre/gretap interfaces are setup with ip link add, which for GRE needs remote and optionally local attributes specifying the endpoints. However, I can't find any way to read back these attributes. ip link show doesn't show them, and they don't seem to be represented anywhere in the data structures returned by the C function getifaddrs (e.g. if I wanted to implement my own tool to get them). I'm working with an environment where there are a very large number of such interfaces, and I need to be able to find the one associated with a particular remote address. Is there any way to do that without storing the mapping somewhere out-of-band?

Here is the setting on server A:

iface serverA_gre0 inet tunnel
        address 172.24.0.85
        mode gre
        endpoint x.x.x.x
        dstaddr 172.24.0.86
        netmask 255.255.255.252
        ttl 255

Setting on server B:

iface serverB_gre0 inet tunnel
        address 172.24.0.86
        mode gre
        endpoint x.x.x.x
        dstaddr 172.24.0.85
        netmask 255.255.255.252
        ttl 255

Without "ttl 255":

traceroute to 172.24.0.86 (172.24.0.86), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  172.24.0.86  54.507 ms  62.888 ms  51.369 ms

With "ttl 255":

traceroute to 172.24.0.86 (172.24.0.86), 30 hops max, 60 byte packets
 1  172.24.0.86  51.123 ms  51.733 ms  51.943 ms

What exactly cause those "*" issue when TTL 255 isn't exists?

I've got a client (Server 2008 R2) that won't connect to our production environment PPTP VPN server (Server 2003, running RRAS).

The server is behind a firewall that has TCP1723 open as well as GRE. Other clients at our office are able to connect just fine. Our office is behind a Juniper SSG5-Serial firewall, but all outgoing traffic is allowed, and multiple other clients are able to connect to VPN servers without issues.

I've also setup a completely different VPN server on another network outside of our office. The functioning clients connect just fine - the Server 2008 R2 machine doesn't. Thus it's definitely a problem with this machine in particular.

I've rebooted it. I've disabled the firewall, no dice on either.

I've run PPTPSRV and PPTPCLNT on the server/client and they're able to communicate perfectly - indicating there's no problem using neither TCP1723 nor GRE.

The Server 2008 R2 machine is also running as a VPN server itself (incoming connection) and that's working perfectly. We have the issues no matter if there are active incoming connections or not.

I'm not sure what my next debugging step would be; any suggestions?

EDIT: The event log on the server has the following warning from RasMan:

A connection between the VPN server and the VPN client xxx.xxx.xxx.xxx has been 
established, but the VPN connection cannot be completed. The most common cause
for this is that a firewall or router between the VPN server and the VPN client
is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47).
Verify that the firewalls and routers between your VPN server and the Internet allow
GRE packets. Make sure the firewalls and routers on the user's network are also
configured to allow GRE packets. If the problem persists, have the user contact
the Internet service provider (ISP) to determine whether the ISP might be blocking
GRE packets.

Obviously this points to GRE being a potential problem. But seeing as I have other clients connectiong without problems, as well as PPTPSRV and PPTPCLNT being able to communicate, I'm suspecting this might be a red herring.

EDIT: Here are the anonymized events logged by the client in chronological order:

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has started dialing a VPN connection using a per-user connection profile named ZZZ. The connection settings are: 
Dial-in User = XXX\YYY
VpnStrategy = PPTP
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = CHAP/MS-CHAPv2 
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = Register primary domain suffix
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY is trying to establish a link to the Remote Access Server for the connection named ZZZ using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has successfully established a link to the Remote Access Server using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The link to the Remote Access Server has been established by user XXX\YYY.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY dialed a connection named ZZZ which has failed. The error code returned on failure is 806.

Running Wireshark on the client shows it trying and retrying to send a "71 Configuration Request"

While the server shows the incoming client requests, but apparently without replying:

Given that this is GRE traffic, I think rules out the GRE traffic being blocked. Question is, why doesn't the server reply?

This is the Configuration Request the server receives from the non functioning client (meaning no response is sent to the client request):

And this is the Configuration Request the server receives from the working client:

To me they seem identical, except for differing keys and magic numbers, and the fact that one client receives a response while the other doesn't.

I'm having a routing problem on CentOS 6.2 (kernel 2.6.32-220)

Here's the setup: One host is on my local network. It's talking to two nearly identical hosts at a remote location. The two remote hosts are on all the same networks, acting as redundant backups for each other.

I set up two GRE tunnels from the local host, one to each remote host:

ip tunnel add name tunnel1 mode gre local 10.2.1.2 remote 10.2.1.1
ip link set dev tunnel1 up
ip route add 172.16.1.0/24 dev tunnel1 metric 101

ip tunnel add name tunnel2 mode gre local 10.2.1.4 remote 10.2.1.3
ip link set dev tunnel2 up
ip route add 172.16.1.0/24 dev tunnel2 metric 102

Outgoing packets route properly, no problem. Incoming packets are weird. It appears that whichever tunnel has the route with the higher metric (tunnel2 in the example above) will ignore incoming packets. They come in all right, and can be seen on the local machine with 'tcpdump -i tunnel2', but they are not routed properly to the local networks. They're simply dropped. I can switch the two metrics, and then tunnel1 will drop all incoming packets. The tunnel with the lower route metric will route packets properly, both incoming and outgoing.

Is this "working as designed?" What I'd like to have happen, of course, is for all packets on both tunnels to be properly forwarded. Is this possible?

Quick update: One person suggested (I'm not sure why) adding 'key' parameters to the 'ip tunnel' commands. I tried this, both with different keys for each tunnel and with identical keys for both tunnels, but neither trial had no effect.

I am configuring a GRE tunnel in Linux 2.6.26 and I've been facing a very strange problem for which I could not find any solution.

I have created a GRE tunnel called gre0, but no matter what I do, I am simply unable to delete this tunnel. The command ip tunnel del gre0 fails with the response ioctl: Operation not permitted. Any attempt to change the addresses of the tunnel also fails.

The following commands illustrate the problem:

# ip tunnel del gre0
ioctl: Operation not permitted
# ip tunnel change gre0
# ip tunnel change gre0 remote <some address> local <some address>
ioctl: No such file or directory

I can create, change and delete other tunnels without any problem, but gre0 just sticks there and does not go away, even if I reboot or take the interfaces down.

If I remove the ip_gre module, the tunnel disappears. As soon as I insert the module again, gre0 reappears and the problem continues.

I have two questions:

1. What can I do to get rid of this pesky tunnel? I suspect this might be a kernel or a module bug.
2. Where such persistent data (in this case, the information for gre0, but this applies to any other setup I may be even unaware of) is stored?

If any other information is needed, please let me know.

Thanks a lot for any help.