2

So, I have managed to get IPSec transport over ESP between two hosts using racoon: the 'local' host, 1.1.1.1, and the remote, 2.2.2.2. It only worked for ICMP (other traffic ignored the SA), but that's a separate problem. In order to try to get all traffic to traverse the secure transport, I decided to setup a GRE tunnel, changing my setkey configuration from

spdadd 2.2.2.2 1.1.1.1 any -P in ipsec esp/transport//require;
spdadd 1.1.1.1 2.2.2.2 any -P out ipsec esp/transport//require;

to

spdadd 2.2.2.2 1.1.1.1 gre -P in ipsec esp/transport//require;
spdadd 1.1.1.1 2.2.2.2 gre -P out ipsec esp/transport//require;

along with the flush; spdflush header.

Essentially, what I did after this was working is setup GRE tunnels on both sides, which were configured correctly to the best of my knowledge but which did not end up getting processed by IPSec, as far as I remember. (Tunnel/endpoint addresses were correct, routing was in place). In any case, I destroyed gre1 on this end and downed gre0, which does not seem to be destroyable.

Now, all traffic to 2.2.2.2 is redirected to lo (according to tcpdump), which is not associated with this address. There is no route for it, nor any iptables forwarding or anything of that sort, and nothing in /etc/hosts. This persists regardless of whether racoon is running -- even if it is returned to exactly the same configuration that worked with ICMP (i.e., the first configuration above).

I'd like to return to the 'correct' state without rebooting, but more than that I am interested in how this behavior is possible given what I've said so far. Happy to provide additional details if they are helpful.

EDIT Additional output, as per Lairsdragon's request:

ip address

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: dummy0:  mtu 1500 qdisc noop state DOWN group default 
    link/ether 0e:09:76:da:e2:22 brd ff:ff:ff:ff:ff:ff
3: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether f2:3c:91:50:42:a1 brd ff:ff:ff:ff:ff:ff
    inet 1.1.1.1/24 brd 1.1.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 ---/64 scope global mngtmpaddr dynamic 
       valid_lft 2591995sec preferred_lft 604795sec
    inet6 ---/64 scope link 
       valid_lft forever preferred_lft forever
4: teql0:  mtu 1500 qdisc noop state DOWN group default qlen 100
    link/void 
5: tunl0@NONE:  mtu 1480 qdisc noop state DOWN group default 
    link/ipip 0.0.0.0 brd 0.0.0.0
6: gre0@NONE:  mtu 1476 qdisc noqueue state DOWN group default 
    link/gre 1.1.1.1 brd 2.2.2.2
    inet 2.2.2.2/8 scope global gre0
       valid_lft forever preferred_lft forever
    inet 10.0.0.1/32 scope global gre0
       valid_lft forever preferred_lft forever
7: gretap0@NONE:  mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: ip_vti0@NONE:  mtu 1428 qdisc noop state DOWN group default 
    link/ipip 0.0.0.0 brd 0.0.0.0
9: ip6_vti0:  mtu 1500 qdisc noop state DOWN group default 
    link/tunnel6 :: brd ::
10: sit0:  mtu 1480 qdisc noop state DOWN group default 
    link/sit 0.0.0.0 brd 0.0.0.0
11: ip6tnl0:  mtu 1452 qdisc noop state DOWN group default 
    link/tunnel6 :: brd ::
12: ip6gre0:  mtu 1448 qdisc noop state DOWN group default 
    link/gre6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

ip route show 2.2.2.2

local 2.2.2.2 dev lo  src 2.2.2.2
    cache  

ip xfrm policy

src 1.1.1.1/32 dst 2.2.2.2/32 proto tcp 
        dir out priority 2147483648 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 1.1.1.1/32 dst 2.2.2.2/32 proto udp 
        dir out priority 2147483648 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 1.1.1.1/32 dst 2.2.2.2/32 proto icmp 
        dir out priority 2147483648 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 2.2.2.2/32 dst 1.1.1.1/32 
        dir fwd priority 2147483648 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 2.2.2.2/32 dst 1.1.1.1/32 
        dir in priority 2147483648 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 

You'll notice a 10.0.0.1 up there in ip address, this was the local endpoint of the tunnel I was trying to make. (Also, just to save face here, I didn't see any relevant output with ip route show, certainly not what we see here with ip route get 2.2.2.2 :/)

  • 1
    Could you please share the output of ip route get 2.2.2.2, ip xfrm policy and ip address? – Lairsdragon Dec 20 '14 at 15:49
  • Thanks for those requests, this information seems to elucidate quite a bit, and from this it seems like I could probably solve this problem by tinkering with ip. I did not have any idea about some of the state here. – A__A__0 Dec 20 '14 at 15:57
0

I like to suggest exec the following commands to clear your network stuff:

Clear the ipsec transform sets

ip xfrm policy flush
ip xfrm state flush

Clear the IP addresses from the unused gre Tunnel:

ip address flush dev gre0

This should remove the unwanted parts from your running network config. Make sure to remove the stuff also from your distros config files.

Edit: Removed the @NONE from the gre0 Interface according to A__A__0 comment.

  • Thanks, this has solved the problem, with the minor modification of removing the '@NONE' from the device name. – A__A__0 Dec 20 '14 at 16:12
  • I where not sure if the @NONE was part of the Interface name or not, thanks for the feedback. – Lairsdragon Dec 20 '14 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.