dhcrelay and ipip tunnels

[Homer Wilson Smith]

      Dear Gentle Folk,

      Running FC3 2.6.12, dhcrelay-3.03.

      SYNOPSIS

      Pointers to RTFM welcome.

      Apparently dhcrelay-3.03 will not run properly across an ipip or
gre tunnel, because the tunnel interface will not properly pick up and
send the return answer from dhcdp.

      Notes on the net claim this is because dhcrelay is using LPF rather
than sockets, but turning on sockets in site.h causes dhcrelay to send
all answers as broadcasts which causes everyone to get all dhcp
responses all the time, including ACKS.

      Do I have this right?

      Is there a way around this problem?  Does 4.x fix it in some
manner?

      Thanks in advance.

      Homer W. Smith
      CEO Lightlink Internet

----------------------------------------------------------------------

      FULL DETAILS

      We have a hotspot system written in perl that depends on a
server/router/client relationship.

      In particular the flow chart looks like this.

      Portal server -> portal router -> portal AP -> portal client.

      The portal server is running DHCPD and our portal code.

      The portal router is a simple two interface linux box running
DHCRELAY.

      The portal AP is something like a ubiquiti pico station in bridge
mode.

      The portal client is any user with a pc or tablet.

      The portal server keeps track of where portal clients are by the IP
subnet range that the client requests via the portal router, running
dhcrelay.  These requested IP's are all private and non routable except
within our own network.

      When a client first comes on, it requests an IP from the server,
say 10.17.4.13, and then when the end user tries to use the web they get
a portal screen via a firewall DNAT redirect on port 80 to the portal
server.  The portal screen asks for a username and password.

      The client enters the username and password, which is sent to the
portal server, which authenticates them, and then the server, using ssh,
installs a new firewall rule on the portal ROUTER, to allow the client
IP to go to the net via SNAT.

      This has worked well for many years.

      Recently we needed to move one of the portal ROUTERS to a remote
ISP network leaving the portal server on our network.

      So now we have:

     Portal Server -> Internet -> Portal router -> Portal AP -> Portal client.
         |                             |
         |---------- ipip tunnel ------|

      This meant creating a tunnel between the server and the router so
that the client using 10.17.4.13 could talk to the portal server across
the net using its 10.17.4.13 address so the server could know who it was
talking to.

      Apparently DHCRELAY-3.03 won't work across a tunnel, because on the
return trip, the tunnel interface won't pick up and send on the dhcpd
answer coming from the server.

      Notes on the net say this is because dhcrelay is using LPF rather
than sockets.  But turning on sockets in site.h seems to cause dhcrelay
to answer EVERYTHING with broadcasts, which means everyone receives all
dhcpd answers all the time, including ACKS.

      The diagram:

     |209.150.237.34 --------- Internet -------- |209.150.237.33
     Core A                                      Core B
     |64.57.182.5                                |
     |                                           -  lots of
     |                                           -  stuff
     |                                           |
     |10.0.2.1      ---  ipip tun interface ---- |10.0.2.2
     |64.57.182.6   ---  ipip tun endpoints ---- |209.150.227.75
     Router A1                                   Router B1 dhcrelay
     |64.57.176.17                               |64.57.177.129
     |                                           |10.17.4.1
     |                                           |
     |64.57.176.23                               |
     Server A2 dhcdp, portal code                |
                                                 Client customers
     On router A1:
     ip route add 10.17.4.0/24 via 10.0.2.2

     On router B1:
     ip route add 64.57.176.16/28 via 10.0.2.1

-----------------------------------------------------------------------

      DETAILS

      We have two core routers, one at our ISP A and the other at ISP B.

      The public statics that connect them route properly between them.

      In particular without the tunnel, machines A, A1 and A2 can telnet,
ftp or ssh to machines B and B1 without problems along the expected
routes.

     In our case the end customer laptops at router B1, are given
private DHCP IPs, in the 10.17.4.1 range.

      When IP's in the 10.17.4.1 range wish to talk to the internet they
are natted to 209.150.237.75 and go out to the net and work fine.

      However these private IP's need to communicate with server A2 using
those private IP's for authentication purposes, for example if machine
10.17.4.20 is talking to server A2, server A2 needs to know it is
talking to 10.17.4.20 and not the natted address.

      Because there is a route on router B1 that directs everything to
Server A2 through the tunnel, and there is a route on Server A2 that
directs everything to 10.17.4.0/28 back to router B1, the tunnel handles
all communications between 10.17.4.0 on B1 and server A2, as it is
supposed.  This all works well for client to portal communications.

      This does not work at all for dchrelay though.  We make dhcrelay
work by placing 10.17.4.1 SECOND in the list ip's for eth1,
so dhcrelay sends the request through the tunnel from 209.150.227.75
instead of 10.17.4.1.  Then the portal server sends it back
across the standard network which works.

      Homer

------------------------------------------------------------------------
Homer Wilson Smith   Clean Air, Clear Water,    Art Matrix - Lightlink
(607) 277-0959       A Green Earth, and Peace,  Internet, Ithaca NY
homer at lightlink.com  Is that too much to ask?   http://www.lightlink.com