1. 19 Feb, 2015 2 commits
  2. 13 Feb, 2015 1 commit
  3. 02 Feb, 2015 2 commits
    • Julien Muchembled's avatar
      Limit number of client tunnels if NAT is not configured properly · 58204ee8
      Julien Muchembled authored
      If too many nodes create client tunnels without serving any, working servers
      saturate and the network collapses.
      58204ee8
    • Julien Muchembled's avatar
      UPnP: randomize external port · 3a9e668c
      Julien Muchembled authored
      Some routers are so broken that UPnP NAT don't report ConflictInMappingEntry
      when redirecting the same port several times.
      
      Here is for example what we had with a Numericable Box (France):
      
      0 (1024, 'TCP', ('192.168.0.29', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
      1 (1024, 'TCP', ('192.168.0.16', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
      2 (1024, 'TCP', ('192.168.0.33', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
      3 (1024, 'TCP', ('192.168.0.20', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
      ('192.168.0.29', 1194, 're6stnet openvpn server (1194/tcp)', True, 0)
      
      Obviously, this can't work.
      
      It seems that this router also accepts a limited number of NAT rules, far less
      than we'd like, so even if there's still a probability of conflict with this
      commit, it will be good enough for our use.
      3a9e668c
  4. 30 Dec, 2014 4 commits
  5. 26 Dec, 2014 3 commits
  6. 18 Dec, 2014 4 commits
  7. 17 Dec, 2014 3 commits
  8. 14 Nov, 2014 1 commit
  9. 03 Nov, 2014 2 commits
  10. 23 Oct, 2014 1 commit
  11. 22 Oct, 2014 1 commit
  12. 21 Oct, 2014 3 commits
  13. 20 Oct, 2014 1 commit
  14. 16 Oct, 2014 1 commit
  15. 09 Oct, 2014 6 commits
  16. 06 Oct, 2014 1 commit
  17. 03 Sep, 2014 1 commit
  18. 02 Sep, 2014 1 commit
  19. 26 Aug, 2014 1 commit
  20. 20 Aug, 2014 1 commit
    • Julien Muchembled's avatar
      Do not fail on unexpected 'route_up' notifications from OpenVPN clients · d7d7b425
      Julien Muchembled authored
      This fixes the following error:
      
        TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'
        Traceback (most recent call last):
          File "/usr/sbin/re6stnet", line 438, in main
            tunnel_manager.handleTunnelEvent(read_pipe.readline())
          File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 389, in handleTunnelEvent
            m(*args)
          File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 412, in _ovpn_route_up
            self._connection_dict[prefix].connected()
          File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 76, in connected
            i = self._retry - 1
      
      What happened is probably that a route_up notification was received just before
      killing/recreating the connection for the same node, and then process twice
      the same OpenVPN notification: in this case, the first was for a previous
      connection and should have been ignored.
      d7d7b425