Applications

Toggle Sidebar
News Feed
  • You should be able to set up custom FORWARD rules to block "NEW" packets from the power generation facility, either by IP/subnet, or, perhaps, the relevant tun interface.

  • Nick Howitt

    Are you sure that in ClearOS 6 you did not have an extra firewall rule which SNAT'd any packets emerging from the tunnel?

    For tcpdump I google "tcpdump examples" and use that. First determine your interface (use the ClearOS LAN interface and monitor that) then you probably just want to pick out packets containint both the source and destination IP's of your test. I always build up my queries bit by bit as I never remember where the brackets and quotes go. I start big then narrow down.

    For the firewall, a couple of rules in your remote machine will do:
    You may want to add narrow down by interface as well but I am not sure. Messages go to /var/log/messages.

  • Nick Howitt wrote:

    ...Following the warning shot from Micro$oft over the summer when (probably due to a bug) Win 10 could no longer join an old-style NT4 domain...


    Hi Nick

    Just as a Side note here:
    That was totally Microsofts Fault as they decided to drop default support to the smb 1.0 protocol. This was easy to get around though but took a bit of hands on work to do - ie add it back through "add windows features". We had that problem at work where all of a sudden all newly staged Laptops (a couple of thousand to be exact) landed outside the domain.

  • Nick Howitt wrote:
    ..

    Thanks for the information. I do know people who work with Red Hat folks on the kernel and nobody likes that back-porting work. Im not saying its not patched, im saying keeping that cruft patched is a terrible job that nobody likes doing. It will be a great relief getting back to where the current versions of things are. RH should not be going 5 years between major releases, bad form.
    I get the 7.6 coming first - but curious when any alpha / very dirty test releases of 8 are planned.

  • Hello Mick,
    The RHEL packages are nowhere as old as they seem. RHEL have a policy aiming for stability, and they back-port patches into their current packages. You will find PHP and Apache are fully patched against all current critical vulnerabilities despite having an old version number. Have a look at

    It is a similar story with the kernel. A lot of the more recent fixes and drivers have been back-ported into the current kernel. I read somewhere that the EL7 kernel is now much closer to 4.10 (I think) rather than the original 3.10.

    Tony has posted as I am typing, but the push at the moment of for 7.6. Personally I'd like to see it released into the community a.s.a.p and into the paid editions in the New Year.

    The change to v8 is going to be much more significant. For a start, RHEL have pulled OpenLDAP as their directory server. Clearcenter would like to try and take ClearOS closer to RHEL/Centos which means using the new RHEl directory server (389 Directory Server). I also believe they want to head towards a more docker containerised architecture if they have the resources. Following the warning shot from Micro$oft over the summer when (probably due to a bug) Win 10 could no longer join an old-style NT4 domain, they like to develop a docker/samba solution for Active Directory support, replacing the withdrawn Samba Directory (Beta) app. I am not sure what else in on the cards.

  • Tony Ellis wrote:
    Not sure that the developers would consider the changes required for ClearOS to go from 7.x -> 8.x "trivial" :)
    Website


    Maybe not trivial - but backporting and catering to ancient versions of things in RH/CentOS 7x vs getting some newer versions of "stuff" fedora 19 -> fedora 28 is a long time and trying to get "stuff" working in fedora 19 era at then end of 2018 (5+ years of time travel) cant be easy or getting any easier. Almost the entire 3.x linux branches are EOL except 3.16.x.

  • With CentOS 7.6 being released on 3 Dec 2018, would expect the immediate priority is to get ClearOS 7.6 out of the door...
    CentOS has released CentOS Linux 7.6 (1810)

    Not sure that the developers would consider the changes required for ClearOS to go from 7.x -> 8.x "trivial" :)

    Tony
    Website

  • Nick Howitt wrote:

    What sort of devices are you trying to connect to? If they are Windows devices, can you please try dropping their firewalls. Also you could try sniffing the packets on the ClearOS LAN interface, either with tcpdump of a firewall rule, but I doubt if you have a problem as the pings are getting through.


    It isn't a client firewall issue. The majority of systems running on the other side are Macs or linux boxes (mostly CentOS 7) with firewall disabled since they are hosting private internal services on a variety of ports for a ton of things.

    If we go back to the start of this problem as well - there were no issues with client connectivity between sites when using ClearOS 6. It was the move to ClearOS 7 that started to create this issue - so it is safe to rule out anything on the client side as none of that has changed between when I had a perfectly working tunnel under COS6 and now. Also, it is important to note that when using OpenVPN to do remote client connectivity everything works as expected to all clients at either site - so client configuration isn't an issue.

    Nick Howitt wrote:
    What may be interesting is seeing the source IP's on the packets as the exit the remote firewall.


    I'd be very interested in some example tests that I could run with TCPDump to determine what might be happening. I'm admittedly a bit of a neophyte with the tool and the documentation listed in this thread is open enough that it is hard to determine where I should even start. Internal IP to external IP? All traffic? From where? To where? I'm happy to do any tests recommended to get this sorted.

  • Nick Howitt

    What sort of devices are you trying to connect to? If they are Windows devices, can you please try dropping their firewalls. Also you could try sniffing the packets on the ClearOS LAN interface, either with tcpdump of a firewall rule, but I doubt if you have a problem as the pings are getting through. What may be interesting is seeing the source IP's on the packets as the exit the remote firewall.

  • Nick Howitt wrote:

    Your traceroutes are completely wrong as nothing is going through the tunnel. You should not see any hops between the IPsec endpoints. If you want to check the tunnel working you should be doing a traceroute to the remote ClearOS LAN IP directly, From A do a traceroute to rightsourceip=192.168.10.1 or any non-Windows device on the remote LAN. The problem with Windows is its firewall, where it may reject pings and other connections from outside its own LAN. You would need to check its settings.


    That's likely because I did external interface to external interface. Doing internal to internal looks like this:

    Firewall up and down are identical in this case (site A to site B, from 192.168.3.1 internal LAN):


    Doing the reverse also works identical with firewall up or down (site B to site A, from 192.168.10.1 internal LAN)



    These are both router to router trace routes, so the tunnel is up and the two end points are responding. Going onto a client at site A and doing a trace route to a known good running machine at site B gets me this:



    However I cannot access any services on that machine (192.168.10.5) through the tunnel - the firewall appears to be blocking all of them.

    If I do the inverse and trace route a machine on site A from a machine on site B I get the following:



    In both cases, the firewall being on/off has no impact to the trace route results. But I can't actually access any services on any machines on the opposite side of the tunnel.

    As soon as I turn off the firewall at both sites, my tunnel works as expected, but now my NAT/forwarding doesn't work at either site (which is expected). So there is a config in iptables that is taking precedent over the tunnel and blocking communications. At this point that is pretty clear because when it is removed from the equation everything works. What I can't figure out is what that setting is or what it is happening the way it is.

    Nick Howitt wrote:
    Similarly if you want to access a web server at B from A, the FQDN at A should resolve to a LAN IP at B and vice versa. This is achieved through the DNS Server settings (or the hosts file)


    It isn't a DNS issue. As I said earlier, completely eliminating DNS 100% from all configs and using only IPs results in the exact same behavior under the same tests. That said, I have full working forward/reverse DNS at both sites for the LANs.