Viewing 22 posts - 1 through 22 (of 22 total)
  • Linux, VMs, firewalls, host networks…
  • molgrips
    Free Member

    And pain.. and trouble..

    I need to get client on one VM talking to server on another. Via http, on a non standard port. On VMWare Workstation, both machines running CentOS 7

    The host-only network seems to work because they can ping each other. This means the routes and interfaces are set up correctly, yes?

    Then the firewall would be the obvious choice, but I’ve disabled it on the server. At least I think I have. Any ideas?

    vorlich
    Free Member

    Have you tried telnetting to the destination port?

    molgrips
    Free Member

    I tried it with a browser…

    damion
    Free Member

    My next steps would be:

    netstat -nlpt

    On the server to check the process is actually running and listening on the expected port.

    Then telnet from the client to server on the port:

    telnet [server ip] [port]

    as basic connectivity tests. To stop and disable the firewall on centos 7:

    systemctl stop firewalld.service
    systemctl disable firewalld.service

    HTH

    DaRC_L
    Full Member

    Yep Ping, Telnet then do you have Linux nslookup program?
    Could be a firewall somewhere in the network – does it use VLAN’s

    molgrips
    Free Member

    Server is running – can connect fine from itself, using both loopback ip and actual ip.

    They are on the same subnet, this is a ‘private virtual network’ ie the host only setting in vmware workstation.

    richc
    Free Member

    On each host run:

    iptables -L

    If that’s accepting connections, the host based firewalls are OK.

    Then try nmap, as that should give you an idea if anything is being blocked

    If you want to double check the routing use traceroute rather than ping as it will show you each hop.

    Other thing to try would be put each VM into Bridged mode and give them a real IP in the same broadcast domain as your host machine and see if they can get to each other. Also it rules out network firewalls as they won’t hit the gateway

    molgrips
    Free Member

    Other thing to try would be put each VM into Bridged mode and give them a real IP in the same broadcast domain

    Will try that.. later.. thanks

    codybrennan
    Free Member

    Also try installing netcat on each machine, running one as server (try a non-standard port) and try connecting to the other as client. Will help to rule out any firewall malarkey.

    When you try to access the server from the client, are you using IP or DNS?

    aracer
    Free Member

    On each host run:

    iptables -L

    ah, but:

    running CentOS 7

    I’m not entirely sure where Centos 7 is in relation to Fedora as I’m still stuck in 32 bit land and haven’t used it, but in the latest Fedora you have firewalld instead of iptables. It used to be standard practice just to do:

    service iptables stop

    to get that one out of the way when testing any network stuff, but now the equivalent runes are:

    systemctl stop firewalld
    systemctl disable firewalld

    …you then have to reboot, as the firewall doesn’t reliably get out of the way until you’ve done that.

    (not that I always do any more as it’s so easy to punch holes in firewalld, I much, much prefer it)

    aracer
    Free Member

    oh and if they can ping each other then the rest of the networking stuff (ie host only) is almost certainly OK – I can’t think of any firewall which might get in the way of that.

    netcat (nc) is extremely good advice – you can easily test connections on different sockets

    molgrips
    Free Member

    I think there are aliases for the iptables commands.

    Anyway, the requirement has passed now, was taking too long. Will still try it another day tho. Ta all.

    scuttler
    Full Member

    Don’t trust the ping. I’ve had bother with it in VMs in the past. Get telnetting on the ports you’re using.

    molgrips
    Free Member

    Huh.. I can ssh to the box, but not http or https.

    Firewall still lives.

    molgrips
    Free Member

    D’oh.

    aracer’s commands worked, once I rebooted.

    brassneck
    Full Member

    Now turn it back on and configure iptables (or firewalld) properly. In case you have to do it for real one day.

    aracer
    Free Member

    aracer’s commands worked, once I rebooted

    HTH – have wasted many hours with similar issues before I realised that despite firewalld claiming not to be running it still gets in the way until you reboot!

    Though as brassneck suggests and I mentioned before, I don’t tend to turn it off anymore, as you just have to do:

    firewall-cmd --add-service=nfs
    firewall-cmd --permanent --add-service=nfs

    in order to allow nfs to work (the first version does it in the running system, the second means it stays open when you reboot)

    I’ve not tried opening ports rather than services, but a quick check suggests “–add-port=443/tcp” is the required command.

    codybrennan
    Free Member

    That looks like a really straightforward bit of config, aracer, thanks for that.

    molgrips
    Free Member

    Yeah I was afraid of config which is why I just turned it off, but that looks great ta 🙂

    aracer
    Free Member

    I should mention that you also have zones with firewalld and those commands just do stuff with the default zone, but for most use that should be fine.

    aracer
    Free Member

    Aaaah, and typically I forget my own advice and wonder why I can’t connect using nc when I’ve stopped firewalld. Have now enabled the required port using –add-port and that works far better!

    brassneck
    Full Member

    I’ve not tried opening ports rather than services, but a quick check suggests “–add-port=443/tcp” is the required command.

    add service is better in general, as you don’t have to run stuff on the well known ports. http on 8080 is’nt uncommon. Think doing that with NFS would just add pain to your life unnecessarily though.

Viewing 22 posts - 1 through 22 (of 22 total)

The topic ‘Linux, VMs, firewalls, host networks…’ is closed to new replies.