Nothing at all but that doesn’t mean anything. Remember here most of the tech support is out sourced so.... sometimes when I call I feel more informed than them.

I have fiber 1gb symmetrical

The output confirms what you've said about your usable IP's.

I suspect ISP issues. Have they asked for anything like VLAN tagging for your extra IP's? What sort of connection do you have to the internet Cable, VDSL/ADSL & PPPoE or whatever?

 ip ro

default via XX.XX.XX.78 dev enp3s0f0

XX.XX.XX.72/29 dev enp3s0f0 proto kernel scope link src XX.XX.XX.73

192.168.50.0/24 dev enp3s0f1 proto kernel scope link src 192.168.50.1

Nick Howitt wrote:

I didn't know you'd tested a port forward on port 80 with your .73 address. All I could see from earlier were your 32400 and 8000 port forwards.

Presumably you have a base address of .72, 73-77 usable, 78 as gateway and 79 as broadcast?

It does tend to indicate an ISP problem if nothing gets through to .74.

What is the output to "ip ro"?

You’re basically spot on now as far as the command you wanted me to run In your last question. Ip ro is this done in ash?

I didn't know you'd tested a port forward on port 80 with your .73 address. All I could see from earlier were your 32400 and 8000 port forwards.

Presumably you have a base address of .72, 73-77 usable, 78 as gateway and 79 as broadcast?

It does tend to indicate an ISP problem if nothing gets through to .74.

What is the output to "ip ro"?

I have a static block of five IPs I assigned clearos one of those IP’s which is the 73. If I use port forwarding and I go to address 73 the devices function correctly. Port 80 and all.

A port forward to which port and IP works? I know 32400 works to .73 which is why I am suggesting to test 32400 to .74. If packets come to your WAN then your ISP is not blocking that port. If they come to your LAN then ClearOS 1-to-1 NAT is working. ISP's have been known to block popular ports such as 25, 80 and 443. One of the earlier tests was port 80 or did you test other ports?

Hey Nick thanks for getting in touch with me. I don’t think my ISP is blocking it. If I do port forwarding the site comes through.

As a thought, you know that 32400 gets through your ISP. You could try connecting to xx.xx.xx.74 port 32400. Even without a machine on your LAN listening, you should see the packets on both interfaces in tcpdump if you change the command to monitor 32400. If you see traffic, then your ISP is blocking common ports.

Be wary of connecting you Plex machine to the 1-to-1 NAT unless it is properly firewalled on other ports. (BTW I run Plex in ClearOS so no port forwards!).

I can't see that multiple NICs will work for your ISP to give you a subnet as he'll need to provide you with you with multiple bits of hardware to interface to ClearOS.

That is weird when the ping works. Either I've got my tcpdump command wrong (possible) or the ISP is filtering packets.

I did it and I got nothing. It did not even move.

As you're getting ping responses from .74, it tends to suggest it is working irrespective of what you see at your ISP. Can I suggest you try the next set of tcpdumps to a port?

Hey Nick I think I found my problem. When I logged in to my ISP's Gateway it showed two connections from my server. But... They were both with the same static IP I am working with my ISP to see if they support 1 to 1 NAT. They have told me that I may need to use multiple NICs in order to assign all the IP's to one equipment. But... That is a commercial / business function and they cannot assist me with that due to me having a residential service.

Please copy and paste the data from the screen rather than post pictures. Also you've failed to munge half your addresses in the tcpdump from your WAN.

To me it means the 1-to-1 NAT is working. I can also get a ping reply.

I've also tried the obvious ports but I can see nothing obvious listening on the .240 IP address, so I think it is either it is firewalled or not responding for some other reason (e.g. if it is a web server such as apache, it is configured to respond only to LAN requests, similarly to a firewall, but not quite the same as it has its own configuration options)

The next thing you can to is the same sort of tcpdump test but with port based traffic:

tcpdump -n -i enp3s0f0 host xx.xx.xx.74 and port 80

and

tcpdump -ni enp3s0f1 host 192.168.50.240 and port 80

Then try to browse to xx.xx.xx.74. You should see traffic hitting your WAN then going through to the LAN, but you may not see any reply of the LAN device is not responding. You can change the port if you know one which you LAN device should be responding to, then use whatever app you would connect to it from your WAN. Or you could drop the port entirely and just monitor all traffic to see what gets through ClearOS.

Please see below

It worked I have echo Reply and echo request on both my Wan and Lan........... What does this mean lol.

I prefer to get it working as well. But options are options. When I get back home I will give what you sent a try thank you

DMZ is different and needs a separate LAN interface.

You won't be able to use the port forwarding module as it uses the WAN IP automatically with the PREROUTING rule it creates, so you'd need to add the three rules it creates manually through the Custom Firewall. Then if you did it without protocols (udp/tcp) and ports, you'd end up with the same thing as 1-to-1 NAT in a more complicated way.

I'd have thought you'd do better to try and get this working to avoid your learning curve getting too steep.

So as an idea if I used virtual interfaces and port forwarding or Dmz I would be doing the same thing?

As far as I know, 1-to-1 NAT does not do any more than port forwarding and setting up virtual interfaces.

The next stage would be to set up teh tcpdump, but for this to be effective you need to have two ssh sessions open at the same time and it is best done on a proper screen so you can see both. In one screen do:

tcpdump -ni enp3s0f0 icmp and host xx.xx.xx.74

and in the other do:

tcpdump -ni enp3s0f1 icmp and host 192.168.50.240

Then, from outside your LAN, ping xx.xx.xx.74. If all goes well you should see packets on both your ssh sessions. You should see traffic coming in (echo request) then return traffic (echo reply). If you see the echo request on both ssh sessions but no echo reply, the issue is on the LAN (or with my command - it takes me a while to work out tcpdump commands)

If that works, then go to the other 2 rules I posted earlier and check some udp or tcp traffic, but you must initiate the traffic from outside your WAN.

[edit]
I've edited a bit the commands I posted earlier to correct and simplify them.
[/edit]

Question is there another way without using the module to make this work I know that if I do port forwarding it works on the first IP of 73.

Last failed login: Fri Mar 30 09:23:24 EDT 2018 from 219.147.23.86 on ssh:notty

There were 3 failed login attempts since the last successful login.

Last login: Fri Mar 30 09:09:45 2018 from msi-stealth.system.lan

[root@gateway ~]# tcpdump -D

1.usbmon1 (USB bus number 1)

2.usbmon2 (USB bus number 2)

3.enp3s0f0

4.enp3s0f1

5.usbmon3 (USB bus number 3)

6.usbmon4 (USB bus number 4)

7.usbmon5 (USB bus number 5)

8.usbmon6 (USB bus number 6)

9.any (Pseudo-device that captures on all interfaces)

10.lo [Loopback]

No Proxy or QOS of any kind basically a clean install with only 1 to 1 Nat installed

As well if you can send me the complete command's you would like for me to run. That way I can acquire information in one step. I am not a CLI guru.

For tcpdump, can you run "tcpdump -D" and post back? It will show me if you can monitor virtual interfaces.

The tcpdump, run in two simultaneous windows should show packets arriving at your WAN interface and then going through the LAN interface at, effectively, the same time. It is a live monitor of traffic and you can do quite extensive filtering of what you want to see.

I'd probably start with the ping monitor, so the two icmp filters. The LAN ping filter should also show return traffic from the LAN device. The WAN ping monitor will only show return traffic if you remove the "dst" from the command. I also got the LAN ping monitor slightly wrong and have corrected it.

The output I was after was from "iptables -nvL". It is different from "iptables -nvL -t nat".

It looks like .73 is your base WAN IP and you've forwarded 2 ports, 8000 and 32400 to different LAN PC's. SSH'ing to that should land you in ClearOS.

You say that you've now three other IP's now set up in 1-to-1 NAT which I can see from ifconfig. I cant see the corresponding iptables nat rules. I can only see the rule for .74. Did you set the other two up after you dumped the nat firewall?

Are the other three devices set up to respond to SSH?

[edit]
Are you by any chance running the proxy or QoS/Bandwidth?
[/edit]

I have done the TCP dump and I dont see anything passing through. Although I dont really know what I am looking at. What I did is I used ClearOS remote access and I went to there first via my LTE Iphone. I saw my IPhone's LTE ip present itself in SSH. Then i went to the other 3 ip's and nothing at all. Although like I said I am not sure if I am doing it correctly.

@gateway ~]# ifconfig | grep ^e -A 4

enp3s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet xx.xx.xx.73  netmask 255.255.255.248  broadcast xx.xx.xx.xx.79

        inet6 2600:1700:17e0:79f0:7ae3:b5ff:fe05:9e4  prefixlen 64  scopeid 0x0<global>

        inet6 fe80::7ae3:b5ff:fe05:9e4  prefixlen 64  scopeid 0x20<link>

        ether 78:e3:b5:05:09:e4  txqueuelen 1000  (Ethernet)

--

enp3s0f0:200: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet xx.xx.xx.75  netmask 255.255.255.248  broadcast xx.xx.xx.79

        ether 78:e3:b5:05:09:e4  txqueuelen 1000  (Ethernet)



enp3s0f0:201: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet xx.xx.xx.74  netmask 255.255.255.248  broadcast xx.xx.xx.79

        ether 78:e3:b5:05:09:e4  txqueuelen 1000  (Ethernet)



enp3s0f0:202: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet xx.xx.xx.76  netmask 255.255.255.248  broadcast xx.xx.xx.79

        ether 78:e3:b5:05:09:e4  txqueuelen 1000  (Ethernet)



enp3s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.50.1  netmask 255.255.255.0  broadcast 192.168.50.255

        inet6 fe80::7ae3:b5ff:fe05:9e6  prefixlen 64  scopeid 0x20<link>

        ether 78:e3:b5:05:09:e6  txqueuelen 1000  (Ethernet)

        RX packets 58452690  bytes 10062630078 (9.3 GiB)

@gateway ~]# lspci -k | grep Eth -A 3

03:00.0 Ethernet controller: Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

        Subsystem: Hewlett-Packard Company NC382i Integrated Multi-port PCI Express Gigabit Server Adapter

        Kernel driver in use: bnx2

        Kernel modules: bnx2

03:00.1 Ethernet controller: Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

        Subsystem: Hewlett-Packard Company NC382i Integrated Multi-port PCI Express Gigabit Server Adapter

        Kernel driver in use: bnx2

        Kernel modules: bnx2

04:00.0 Ethernet controller: Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

        Subsystem: Hewlett-Packard Company NC382i Integrated Multi-port PCI Express Gigabit Server Adapter

        Kernel driver in use: bnx2

        Kernel modules: bnx2

04:00.1 Ethernet controller: Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

        Subsystem: Hewlett-Packard Company NC382i Integrated Multi-port PCI Express Gigabit Server Adapter

        Kernel driver in use: bnx2

        Kernel modules: bnx2

I have tried three separate devices. Including

HP iLo 3 Server Remote management
Dell IDRAC Server Remote Management
Netgear R8500 Wireless router.

None of them are working.

Nick Howitt wrote:

Do you have the other iptables listing? I've tried looking at your snapshots and I suspect you don't have ClearOS issue. The tcpdumps should show that if you see a packet hit the WAN interface and immediately go through to the LAN interface with the correct destination IP.

My suspicion is a Windows firewall which often blocks requests not coming from its LAN.

I will work on getting that for you now. FYI this device is iLo which is a remote management for a server. Not Windows Firewall and as a matter of fact to Firewall at all.

Do you have the other iptables listing? I've tried looking at your snapshots and I suspect you don't have ClearOS issue. The tcpdumps should show that if you see a packet hit the WAN interface and immediately go through to the LAN interface with the correct destination IP.

My suspicion is a Windows firewall which often blocks requests not coming from its LAN.

 iptables -nvL -t nat

Chain PREROUTING (policy ACCEPT 83638 packets, 20M bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            xx.xx.xx.73          tcp dpt:32400 to:192.168.50.207:32400

   10   540 DNAT       tcp  --  *      *       0.0.0.0/0            xx.xx.xx.73          tcp dpt:8000 to:192.168.50.242:8000

   19   970 DNAT       all  --  *      *       0.0.0.0/0            xx.xx.xx.74          to:192.168.50.240



Chain INPUT (policy ACCEPT 14031 packets, 1309K bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain OUTPUT (policy ACCEPT 11886 packets, 742K bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain POSTROUTING (policy ACCEPT 901 packets, 59852 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

    0     0 SNAT       tcp  --  *      *       192.168.50.0/24      192.168.50.207       tcp dpt:32400 to:192.168.50.1

    0     0 SNAT       tcp  --  *      *       192.168.50.0/24      192.168.50.242       tcp dpt:8000 to:192.168.50.1

    0     0 SNAT       all  --  *      *       192.168.50.240       0.0.0.0/0            to:xx.xx.xx.74

   10   640 SNAT       all  --  *      *       192.168.50.0/24      192.168.50.240       to:192.168.50.1

25177 3201K MASQUERADE  all  --  *      enp3s0f0  0.0.0.0/0            0.0.0.0/0

[root@gateway ~]#

Sorry incorrectly used the code tags.

I replied to this yesterday but I guess I forgot to hit the Reply button.

Please can you give your iptables output as a proper listing as I find it harder to read the screenshot? In PuTTy, if you select text, it automatically copies it to the clipboard and you can then paste into the forum (between "code" tags, please). If you munge your external IP addresses, please can you at least leave in the last octet which, from your earlier posts, are .68 and .69. It makes it a bit easier to track which rule belongs to what. As an alternative to copying in PuTTy, you could redirect the output to a file by adding something like "> firewall.txt" to the iptables command.

Can you also give the output to:

iptables -nvL -t nat

Again, between "code" tags.

Your other two screen shots are fine and show no issues.

Please see attached and thank you for your help. If Blocking the IP's doesnt allow you to fully understand what is occuring we will have to find another way. I am not a fan of putting public IP's on the net.

This my findings I dont see that it was added to the Table.

I will mention after trying to get to the server remotely I was able to Ping the ip and I am getting a response back. I am going to attempt what you were asking me to do. In order to do that I have to enable remote ssh and login as I am at work now. Let me see how this goes. I am not CLI friendly kinda of guy. lol.

Your posts should automatically start appearing now the first couple have been approved.

With 1-to-1 NAT set up can you post your main firewall:

iptables -nvL

Please put it between "code" tags (the piece of paper icon with a <> on it).

If you have opened the incoming firewall for that port, please close it and test again?

What is the output from:

ifconfig | grep ^e -A 4

lspci -k | grep Eth -A 3

I am not good with tcpdump and have never tried it with virtual interfaces which 1-to-1 NAT uses but if you open a couple of SSH sessions you can try in one:

tcpdump -n -i your_WAN_interface and host your_WAN_IP

If you know the port you are testing with you can add "and dst port 80", or, if pinging (icmp protocol), try:

tcpdump -ni your_wan_interface icmp and host your_wan_IP

Do something similar on the LAN interface:

tcpdump -n host your_target_LAN_IP -i your_LAN_interface and dst port 80

or

tcpdump -ni your_LAN_interface icmp and host your_target_LAN_IP

You should see matching packets going through ClearOS. For the WAN interface, I am not sure if you use the virtual interface or actual interface name. Do a "tcpdump -D" to see a list of available interfaces.

After doing some research it would appear that the firewall is blocking it. IP address locators are able to confirm my public IP changed but there is no packets coming back from the wan through the firewall to the device.

Yep 1 to 1 nat is not working. When I switch over the device to port forwarding it works correctly and shows the data. But when I attempt via 1 to 1 Nat it does not operate. Not sure but I have not made any firewall rules nor have a made any virtual IP's and I have nothing. Any community help is greatly appreciated.

Thanks

I can also say that from internally it does work when I use my dedicated wan IP so some form of NAT is working I just need to figure it out I am going to try to restart the server now.