Redirect to wrong IP destination.

[sbeaudoin]

I have a NAT rule to redirect paquets from WAN port 50443 to IP 10.0.20.7 port 443. I access my WAN address from my cell phone (wifi disabled) with "https://[wan address]:50443" but it redirects me to port 443 of 10.0.20.6. The firewall rule is working as I can see the page from my web server at 10.0.20.6 as if I typed "https://10.0.20.6".

If I turn off the web server on 10.0.20.6, I have a 404 page instead. So, it really redirect to 10.0.20.6. I was using aliases, but I use the full IP address and port. I tried to delete and recreate the rule without any changes. I also tried to use 55555 as the inbound port without changes.

I am a Windows guy, so I don't know how to list the NAT rules from the command prompt or anything command related.

I have 4 other NAT rules and they work fine.

[viragomann]

Delete the browser cache or try another browser.

[sbeaudoin]

Tried with chrome and Firefox. Also tried after clearing the browser history. No joy.

[Gertjan]

@sbeaudoin said in Redirect to wrong IP destination.:

I am a Windows guy

So you are aware of the world number one key board rule : Ctrl-C and Ctrl-V (Copy and Paste).

Use a tool like SnippingTool (SnippingTool.exe) and select your rules,
Paste the image in your post.
Like this :

To check my Alias, I checked the popup ^^

Because I'm using an Alias - and I think and meant that that one should be 192.168.1.4 I used the appropraite tools to double check that :

Because I still doubt, I have another check :

A NAT rule has a related firewall rule :I check that :

which shows me :

On this page I find the same Alias - which I already checked (I guess ...).

Because I'm someone that still doesn't trusts GUI's, I also checked the real thing :
Console => option 8
and had a look at the config.xml fil at <pfsense><nat><rule> ...

<rule>
			<source>
				<any></any>
			</source>
			<destination>
				<network>wanip</network>
				<port>1234</port>
			</destination>
			<protocol>tcp</protocol>
			<target>PowerEdge</target>
			<local-port>3389</local-port>
			<interface>wan</interface>
			<descr><![CDATA[MSTSC]]></descr>
			<associated-rule-id>nat_5c463c8d942669.49042019</associated-rule-id>
			<created>
				<time>1548106893</time>
				<username>admin@2001:470:ccea:2::1000 (Local Database)</username>
			</created>
			<updated>
				<time>1550159907</time>
				<username>admin@2001:470:1f13:5c0:2::c6 (Local Database)</username>
			</updated>
		</rule>

search the "associated-rule-id" and check that one also.

Btw : do also some LAN side test like : MAC addresses ok ?

edit : normally @Grimson drops by to post
https://docs.netgate.com/pfsense/en/latest/book/nat/index.html

I do confirm that if you declare an Alias that contains 1.2.3.4 then it will not use 1.2.3.5 after wards.
This forum would explode with complaints in that case.

[sbeaudoin]

@gertjan, yeah, I know what a print screen is, even if i'm a Windows guy ;-). I am confident of the product and I'm sure the problem is me, misunderstanding something. I will try to use the duckie method (https://en.wikipedia.org/wiki/Rubber_duck_debugging) and use your process to see if I find something.

Here is my NAT rule. As you can see, I tried to solve my problem by removing all aliases. The non-related entries are blured and, as they use aliases, I used the tooltip to be sure they point to the correct value. None of these rules, naturally, use port 55555 nor IP address 10.0.20.7.

Then come the firewall rule related to this NAT.

And the details (I will try, after this, to assign IPv4 addresses only) :

You lost me at the console 8 because when I do that, I have the shell prompt and I don't even want to begin to type sudo something until i'm blue ;-) Have been able to quit the shell with Ctrl-D (I think, tried many things). So, I used thr web interface "Diagnostics > Edit File" to edit "/conf/config.xml" and here is the NAT rule :

                    <rule>
			<source>
				<any></any>
			</source>
			<destination>
				<network>wanip</network>
				<port>55555</port>
			</destination>
			<protocol>tcp</protocol>
			<target>10.0.20.7</target>
			<local-port>443</local-port>
			<interface>wan</interface>
			<descr><![CDATA[PRTG Redirect]]></descr>
			<associated-rule-id>nat_5c648cf948bb57.79788935</associated-rule-id>
			<created>
				<time>1550093561</time>
				<username>admin@10.0.20.100 (Local Database)</username>
			</created>
			<updated>
				<time>1550095453</time>
				<username>admin@10.0.20.100 (Local Database)</username>
			</updated>
		</rule>

As you can see, the port and the IP is good. And as I am already here, here is the filter rule, on the LAN side :

		<rule>
			<source>
				<any></any>
			</source>
			<interface>wan</interface>
			<protocol>tcp</protocol>
			<destination>
				<address>10.0.20.7</address>
				<port>443</port>
			</destination>
			<descr><![CDATA[NAT PRTG Redirect]]></descr>
			<associated-rule-id>nat_5c648cf948bb57.79788935</associated-rule-id>
			<tracker>1550093561</tracker>
			<created>
				<time>1550093561</time>
				<username>NAT Port Forward</username>
			</created>
		</rule>

I also searched all that references 10.0.20.6. It is first referenced as the DNS server in the "PFSense > System Section" (10.0.20.6 is the domain controller - Windows Server 2016). It is also found in the "PFSense > DHCPD > LAN" as the WINS server (correct) and the DNS server. The third and last occurrence is at the alias definition "PFSense > Aliases" used in two other rules.

Did the same thing for 10.0.20.7. It is referenced as a static DHCP entry in "PFSense > DHCPS > LAN" and made sure the MAC is not anywhere else. It is also assigned as a the NAT and filter rule specified above.

So, the rubber duckie did not work this time and I am still lost. But this is a positive experience as this produce a bunch of information for someone else to help me ;-).

[sbeaudoin]

@gertjan. Did try with IPv4 only, still no joy.

[Derelict]

If the wrong server is responding then the wrong server is responding to 10.0.20.7.

Do a packet capture on the inside interface for connections to 10.0.20.7 TCP port 443.

Test a connection in from the outside.

Do you see the SYN going out the local interface? Is it destined for 10.0.20.7? What responds?

You might need to look at the MAC addresses here to see what's really going on.