On 19.08.17 19:23, Ray via luv-main wrote:
I am doing some testing on this set up and I am unable to talk to the Dlink 4G router, IT is connected by a short cat5 cable to the eth0.
Of the firewall host mentioned upthread? (It is the only one described as having two ethernet ports, IIRC.)
This port is setup with an address of 192.168.1.6 and is the default route for the machine.
Sounds like the firewall. We'll keep guessing on this track. But that IP will only be seen by the modem (i.e. inward traffic), and the default route is for outward traffic, i.e. all the world's IPs other than your inboard subnet.
Eth1 is connected to my switch connected to my other machine, this port has an address of 192.168.1.1 (ie my gateway machine)
Now you have the 192.168.1.0/24 subnet on both sides of the firewall. Can you please post e.g. the output of "netstat -rn", to show how you're routing traffic through the firewall? (It can be split finer, but is it?)
Both interfaces are up. THe IP address of the Dlink 4G router is 192.168.0.1, when I point a browser at this address (either Firefox of links2) there is no response, ifconfig shows some data is excahanged (around 200 bytes tranmsited and 50 received, so the connection appears to work.
A forward route is only half the story. What do ping and traceroute report? Here, my modem is on the same subnet: $ ping router PING router (192.168.1.1) 56(84) bytes of data. 64 bytes from router (192.168.1.1): icmp_req=1 ttl=64 time=0.599 ms That tells me that there is a return path. $ traceroute router traceroute to router (192.168.1.1), 30 hops max, 60 byte packets 1 router (192.168.1.1) 0.548 ms 0.644 ms 0.836 ms If I had a firewall in between, that'd tell me whether I'm reaching the near port or the far one, IIRC.
What am I doing wrong, everyone makes out it is simple to communicate with these things.
It's not so simple that it can be done for the first time, without looking. And it's only simple after you've cancelled out the false assumptions, and done it right. E.g. a missing return route will stymie a ping, despite the forward path being peachy.
What config is required to talk to one of these self contained routers connected to an ethernet port.
Is the assumption that the router can't reply supported by a failed ping from the firewall host? If so, the long description above isn't part of the problem. If the router isn't trusted, temporarily substitute another host, using the same IP, and test your hops from both ends - as one might test the links of a chain. Assumptions tend to fall like dandruff, then. Happy hunting. :-) Erik