[Openswan Users] openswan, alias interface and advanced routing (very long)

Giovani Moda - MR Informática giovani at mrinformatica.com.br
Tue Oct 23 15:47:25 EDT 2007


Ok, my bad. Let me clear it up a bit:

eth0 = 189.2.x.x
eth0:0 = 189.2.x.y

only the last block changes.

I _think_ the SNAT rule is the problem, 'cause that's the only thing I think would cause packets from server2 to 189.2.x.y (eth0:0) to be detected and nated. I'll try to exclude 189.2.x.y from the SNAT rule and see how it goes, but I _think_ I might have already tried it. I've done so much changes on the last couple of days that I don't really know for sure.

Thanks,

Giovani Moda

  ----- Original Message ----- 
  From: Peter McGill 
  To: 'Giovani Moda - MR Informática' ; users at openswan.org 
  Sent: Tuesday, October 23, 2007 5:30 PM
  Subject: RE: [Openswan Users] openswan,alias interface and advanced routing (very long)


  If I've understood your post correctly you have a public eth0 interface with a 189.2.x.x IP,
  and a virtual eth0:0 with a different (similar) IP, which I'll call 189.2.v.v.
  Your IPSec traffic using eth0:0 is incorrectly being NATed to 189.2.x.x by your SNAT rule?
  (Note: if you have more than one IP in 189.2.x.x range then don't mask both as .x.x!
  It's confusing as hell and impossible to determine which routes go where...
  If you hide your IPs at least uniquely identify each.)

  If that's the case then try this change:
  $IPTABLES -t nat -A POSTROUTING -o eth0 -s ! 189.2.v.v -j SNAT --to-source 189.2.x.x


  Peter McGill




----------------------------------------------------------------------------
    From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On Behalf Of Giovani Moda - MR Informática
    Sent: October 23, 2007 2:11 PM
    To: users at openswan.org
    Subject: [Openswan Users] openswan,alias interface and advanced routing (very long)


    Hello,

    It's been a while since I don't need your help, but I've been pulling my hair out on this one and can't seem to figure it out. Here it goes:

    I have two servers connected trhough three tunnels:

    net1-to-net2
    server1-to-net2
    net1-to-server2

    In this particular case, I had to create the tunnels using an alias interface of eth0, since the servers exchange non encrypted communication, wich is huge and would overload the tunnels if encrypted. In both servers, the external interface is eth0, and there are aliases interfaces eth0:0. I can do that, since both ends have up to four valid ips I can use. So, the scenario is something like:

                                
    net1 -> eth0:0 -> eth0 -> internet -> eth0 -> eth0:0 -> net2

    To make things more difficult (of course), at server1, there's a second internet link, on wich there are traffic control rules. That would be eth2. To acomplish the balancing between those links, a set of advanced rules using ip rule have been created. I'll not mention the HTB rules here, since they are specifically bonded to eth2, and only eth2. And that's where all the problems began. It was all working 'till I've added that second link and subsequent advanced rules.

    Here are the advanced routing rules:

    ip rule
    0:      from all lookup local
    18:     from all fwmark 0x3 lookup router1
    19:     from all fwmark 0x4 lookup router2
    20:     from all fwmark 0x5 lookup router3
    22:     from 189.2.x.x lookup router3 --> ip of eth0:0
    22:     from 189.2.x.x lookup router1 --> ip of eth0
    23:     from 189.19.x.x lookup router2 --> ip of eth2
    32766:  from all lookup main
    32767:  from all lookup default


    ip route show main
    189.2.x.x via 189.2.x.x dev ipsec1 
    189.2.x.x/26 dev eth0  proto kernel  scope link  src 189.2.x.x
    189.2.x.x/26 dev ipsec0  proto kernel  scope link  src 189.2.x.x
    189.2.x.x/26 dev ipsec1  proto kernel  scope link  src 189.2.x.x
    189.19.x.x/24 dev eth2  proto kernel  scope link  src 189.19.x.x
    172.31.72.0/22 via 189.2.x.x dev ipsec1
    172.31.68.0/22 dev eth1  proto kernel  scope link  src 172.31.68.1
    default
            nexthop via 189.2.x.x  dev eth0 weight 1
            nexthop via 189.19.x.x  dev eth2 weight 1

    ip route show table router1
    189.2.x.x/26 dev eth0  scope link  src 189.2.x.x --> ip of eth0
    189.19.x.x/24 dev eth2  scope link  src 189.19.x.x
    172.31.68.0/22 dev eth1  scope link  src 172.31.68.1
    127.0.0.0/8 dev lo  scope link
    default via 189.2.x.x dev eth0  src 189.2.x.x --> ip of eth0

    ip route show table router2
    189.2.x.x/26 dev eth0  scope link  src 189.2.x.x
    189.19.x.x/24 dev eth2  scope link  src 189.19.x.x
    172.31.68.0/22 dev eth1  scope link  src 172.31.68.1
    127.0.0.0/8 dev lo  scope link
    default via 189.19.x.x dev eth2  src 189.19.x.x --> ip from eth2

    ip route show table router3
    189.2.x.x/26 dev eth0  scope link  src 189.2.x.x --> ip of eth0:0
    189.19.x.x/24 dev eth2  scope link  src 189.19.x.x
    172.31.68.0/22 dev eth1  scope link  src 172.31.68.1
    127.0.0.0/8 dev lo  scope link
    default via 189.2.x.x dev eth0  src 189.2.x.x --> ip of eth0:0


    Some iptables rules to direct the traffic to it's desirable destination:
    $IPTABLES -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 189.2.x.x  # make eth0 traffic go through eth0
    $IPTABLES -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 189.19.x.x  # make eth2 traffic go through eth2
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 80 -j MARK --set-mark 3 # http-trafic
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 443 -j MARK --set-mark 3 # http-trafic
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 25 -j MARK --set-mark 4 # smtp
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 110 -j MARK --set-mark 4 # pop3
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 143 -j MARK --set-mark 4 # imap
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 20 -j MARK --set-mark 4 # ftp
    $IPTABLES -t mangle -A PREROUTING -p tcp -i eth1 --dport 21 -j MARK --set-mark 4 # ftp
    $IPTABLES -t mangle -A PREROUTING -p udp -i eth1 --dport 500 -j MARK --set-mark 5 # ipsec identify redirected to table router3
    $IPTABLES -t mangle -A PREROUTING -p udp -i eth1 --dport 4500 -j MARK --set-mark 5 # ipsec nat-t redirected to table router3
    $IPTABLES -t mangle -A PREROUTING -p ah -j MARK --set-mark 5 # ipsec trafic redirected to table router3
    $IPTABLES -t mangle -A PREROUTING -p esp -j MARK --set-mark 5 # ipsec trafic redirected to table router3
    $IPTABLES -t mangle -A POSTROUTING -p ah -j MARK --set-mark 5 # ipsec trafic redirected to table router3
    $IPTABLES -t mangle -A POSTROUTING -p esp -j MARK --set-mark 5 # ipsec trafic redirected to table router3
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 3 # http-trafic
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 3 # http-trafic
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 4 # smtp
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 110 -j MARK --set-mark 4 # pop3
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 20 -j MARK --set-mark 4 # ftp
    $IPTABLES -t mangle -A OUTPUT -p tcp --dport 21 -j MARK --set-mark 4 # ftp
    $IPTABLES -t mangle -A OUTPUT -p udp --dport 500 -j MARK --set-mark 5 # ipsec identify redirected to table router3
    $IPTABLES -t mangle -A OUTPUT -p udp --dport 4500 -j MARK --set-mark 5 # ipsec nat-t redirected to table router3

    and finally my ipsec.conf
    #
    config setup
            klipsdebug=none
            plutodebug=none
            interfaces="ipsec0=eth0 ipsec1=eth0:0"
            nat_traversal=yes
            uniqueids=yes
            virtual_private=%v4:10.0.0.0/8,%v4:!172.31.0.0/12,%v4:192.168.0.0/24,%v4:192.168.1.0/24,%v4:192.168.2.0/24

    conn %default
            compress=yes
            disablearrivalcheck=no

    conn sp-to-pira
            keyingtries=0
            authby=rsasig
            left=189.2.x.x --> ip of eth0:0
            leftnexthop=189.2.x.x
            leftsubnet=172.31.68.0/22
            leftid=@pira...
            leftrsasigkey=
            right=189.2.x.x
            rightnexthop=189.2.x.x
            rightsubnet=172.31.72/22
            rightrsasigkey=
            rightid=@sp...
            auto=start

    conn sp-to-piranet
            keyingtries=0
            authby=rsasig
            left=189.2.x.x --> ip of eth0:0
            leftnexthop=189.2.x.x
            leftsubnet=172.31.68.0/22
            leftid=@pira...
            leftrsasigkey=
            right=189.2.x.x
            rightnexthop=189.2.x.x
            rightrsasigkey=
            rightid=@sp....
            auto=start

    conn pira-to-spnet
            keyingtries=0
            authby=rsasig
            left=189.2.x.x --> ip of eth0:0
            leftnexthop=189.2.x.x
            leftid=@pira...
            leftrsasigkey=
            right=189.2.x.x
            rightnexthop=189.2.x.x
            rightsubnet=172.31.72.0/22
            rightrsasigkey=
            rightid=@sp...
            auto=start

    conn MR-AS
            authby=rsasig
            rightcert=mr.pem
            rightid="C=BR..."
            auto=add
            also=l2tp-ipsec

    conn RD1-AS
            authby=rsasig
            rightcert=rd1.pem
            rightid="C=BR..."
            auto=add
            also=l2tp-ipsec

    conn l2tp-ipsec
            pfs=no
            left=189.2.x.x --> ip of eth0
            leftcert=mail1.pem
            leftrsasigkey=%cert
            leftsendcert=yes
            leftprotoport=17/1701
            right=%any
            rightca=%same
            rightprotoport=17/1701
            rightrsasigkey=%cert
            rightsubnet=vhost:%no,%priv
            rekey=no

    include /etc/ipsec.d/examples/no_oe.conf

    #
    So, all server-to-server and net-to-net traffic is supposed to go through eth0:0 IP, and all roadwarrios connections through eth0 IP. The problem is: it's not. All ipsec thaffic is reaching the other end with IP from eth0, and not eth0:0, giving me this at server2:

    pluto[869]: packet from 189.2.x.x:500 (server1 eth0:0): initial Main Mode message received on 189.2.x.x:500 (server2 eth0:0) but no connection has been authorized. (obviously)

    And the MOST curious is that in server1 logs, I get a tunnel estabilished through NAT-T with server2:

    pluto[1490]: "sp-to-piranet" #38: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
    pluto[1490]: "sp-to-piranet" #38: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}

    Biy server2 IS NOT nated. There's a route mix up somewhere wich leads server1 to believe that packets delivered to eth0:0 are being nated.

    So, as result, from server2 I can ping both server1 and subnet1, but not the other way around. Except if I ping explicitly from the internel interface (eth1), wich does not work for my purposes.

    ping 172.31.72.2
    PING 172.31.72.2 (172.31.72.2) 56(84) bytes of data.
    --- 172.31.72.2 ping statistics ---
    2 packets transmitted, 0 received, 100% packet loss, time 999ms

    ping -I eth1 172.31.72.2
    PING 172.31.72.2 (172.31.72.2) from 172.31.68.1 eth1: 56(84) bytes of data.
    64 bytes from 172.31.72.2: icmp_seq=1 ttl=127 time=37.1 ms
    64 bytes from 172.31.72.2: icmp_seq=2 ttl=127 time=33.9 ms
    64 bytes from 172.31.72.2: icmp_seq=3 ttl=127 time=33.8 ms
    --- 172.31.72.2 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms

    All roadwarriors connections are working. I'm pretty sure the problem relies on:

    $IPTABLES -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 189.2.x.x

    But I cannot make the advanced rules work without it. I've already tried. And I can't find a way to tell iptables to not SNAT packets with source IP of eth0:0. So, can anyone please help me? Any suggestion would be dearly appreciated.

    Thanks, and sorry for the very, very long post.

    Giovani Moda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20071023/dc8a05f3/attachment-0001.html 


More information about the Users mailing list