#2 use of FQDNs instead of IP-addresses

closed
nobody
None
5
2009-01-16
2004-08-09
Anonymous
No

i've got 2 hosts on the internet with changing
IP-addresses at least every 24hours. each hosts
reconnects immediatelly and updates its DNS-entry (at
dyndns.org). using hostnames instead of IP-addr with
setkey works, but it immediatelly resolves them and
then these IP-addresses (in the policies) are never
updated again, thus the IPsec (transport) -connection
between the two is gone. ok, i could put a one-liner in
the ppp-up-script calling setkey, but if the two hosts
don't redial about the same time, i always have to
check if the peer's DNS-entry has changed and then call
setkey again. so using FQDNs would be much nicer; this
was possible with FreeS/WAN, IIRC. so, the DNS was
always asked when phase 1 started -- of course this is
somewhat lavish, but otherwise i'd have to check
automanually (cron) (much more lavish in case of a
seldomly used IPsec-connection).
is this possible with recent ipsec-tools and linux 2.6?
are there any plans to implement this feature? TIA

/Holger Duell

Discussion

  • Aidas Kasparas

    Aidas Kasparas - 2004-08-10

    Logged In: YES
    user_id=39627

    Hi, Holger,

    I agree -- it would be good to have feature you're
    requesting. Unfortunatelly, with 2.6's ipsec architecture it
    is close to imposible to implement it (or at least I have no
    idea, how to do so). And this is why.

    All the "dirty" work (finding out, should packet be subject
    of ipsec processing, en/de-capsulations) is done by kernel.
    To make these decissions kernel maintains SPD (Security
    Policy Database). All the addresses in that database are
    held in IP form. And there is a good reason for that -- this
    database is consulted for _EVERY_ packet. So, if we would
    put FQDN here, then we would need to send some dns packets
    first to find out, if given rule should apply. But these
    packet should be subject to SPD rule check => we get
    infinite loop. And therefore we CAN NOT use FQDNs in
    selectors => transport mode becomes unuseable.

    For tunnel mode there is no such fundamental problem AFAIK.
    But to implement it one would need to:
    - invent syntax, how to specify, that FQDN addresses should
    not be resolved;
    - modify kernel, to accept, store and return policies with
    tunnel endpoints as strings;
    - modify ipsec-tools to know how to deal with such policies.

    I'm affraid, advocating changes in kernel woult be not an
    easy task.

    May I suggest a workaround? You can listen on some port
    (using xinetd), and on every (rate-limited) connection to
    that port, you could check dns for peer's address changes
    and update setup accordingly. Your ip-up then should telnet
    to that port after it has registered it's IP in dns. You may
    need to setup extra rule in ipsec to allow packets on that
    port through.

     
  • Nobody/Anonymous

    Logged In: NO

    i use dynamic DNS for most nodes and have approached the
    situation from a totaly different angle ...

    i use IPSEC in transport mode to protect the end points of a GRE
    tunnel so the GRE is protected this allows me multicast routing and
    use of OSPF/RIP/BGP

    i have a script that runs from cron that checks the ADSL link is
    up/down and restarts it if needed (useing 3G wireless is more
    prone to disconnects) and then resolves and pings the tunnel
    endpoint if it cant reach the SPD is updated and IPSEC comes op ...

    using GRE allows me to firewall/route/LB connections and is IMHO a
    better solution than pure tunnel mode yes it is lavish and has more
    overhead but is very stable.

     
  • Timo Teras

    Timo Teras - 2009-01-16

    Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you.

     
  • Timo Teras

    Timo Teras - 2009-01-16
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks