Webgui and SSH listening on wrong ip

3zzz

What is that at the bottom about a port forward on port 80? Is there some sort of port forward in the NAT rules?

You have 443 turned off so it's only on port 80.

That was me experimenting last night trying to get in, i added a NAT rule to forward port 80 on the WAN side to the LAN interface,
from NAT page, the rule I added last night (it did not grant me access)

UPDATE: I changed those to WAN interface / WAN address and I now can access pfsense from outside on the public ip. Still can't access it from inside on the private ip, times out: http://192.168.1.1/

cheers

Derelict

Diagnostics > Packet Capture

Interface: LAN
Protocol: TCP
Host address: 192.168.1.1 (Whatever LAN address is)
Port: 80
Count: 10000

Press Start

Make a couple connection attempts from LAN to http://192.168.1.1:80/ - Yes, please be that specific in the URL. Try a couple of browsers especially if you have one around that you never use like IE or Safari.

Go back to Diagnostics > Packet Capture and press Stop

Post what is there.

You can change the level of detail there and press View capture to see more detail if you like. You can Download Capture to get the pcap for study in Wireshark, etc, if desired.

3zzz

coincidentally i was basically just doing more or less what you've asked, came back here and found your post.
I connected to a local windows box and captured those packets,

13:11:11.479523 IP (tos 0x0, ttl 128, id 26991, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.168.56280 > 192.168.1.1.80: Flags [s], cksum 0x1234 (correct), seq 1438877430, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
13:11:11.479715 IP (tos 0x0, ttl 128, id 26992, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.168.56281 > 192.168.1.1.80: Flags [s], cksum 0xbc2f (correct), seq 3263197244, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
13:11:11.730817 IP (tos 0x0, ttl 128, id 27004, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.168.56282 > 192.168.1.1.80: Flags [s], cksum 0x6c4b (correct), seq 1244346485, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

no ack from pfsense.  i will try again with the exact specific url, just in case - thank you for your help!
[/s][/s][/s]

3zzz

OK did it again, copied and pasted the exact url with port 80 and the slash. Tried 3 browsers, 2 of which are never used. Here's the result with "normal" detail level:

13:17:39.874241 IP 192.168.1.168.56622 > 192.168.1.1.80: tcp 0
13:17:39.874747 IP 192.168.1.168.56623 > 192.168.1.1.80: tcp 0
13:17:40.124688 IP 192.168.1.168.56625 > 192.168.1.1.80: tcp 0
13:17:42.871083 IP 192.168.1.168.56622 > 192.168.1.1.80: tcp 0
13:17:42.871114 IP 192.168.1.168.56623 > 192.168.1.1.80: tcp 0
13:17:43.120066 IP 192.168.1.168.56625 > 192.168.1.1.80: tcp 0
13:17:43.404719 IP 192.168.1.168.56627 > 192.168.1.1.80: tcp 0
13:17:46.406182 IP 192.168.1.168.56627 > 192.168.1.1.80: tcp 0

Derelict

Diagnostics > Command Prompt

What does this output?

netstat -an | grep -i listen

3zzz

swapped out the hostname and public ip address, this is the output:

[2.2.1-RELEASE][admin@my.hostname.net]/root: netstat -an | grep -i listen
tcp4       0      0 AA.BB.CC.DD.1194      *.*                    LISTEN
tcp6       0      0 *.53                   *.*                    LISTEN
tcp4       0      0 *.53                   *.*                    LISTEN
tcp6       0      0 *.80                   *.*                    LISTEN
tcp4       0      0 *.80                   *.*                    LISTEN
tcp4       0      0 *.222                  *.*                    LISTEN
tcp6       0      0 *.222                  *.*                    LISTEN
[2.2.1-RELEASE][admin@
[/code]

so yeah it's listening, and ipconfig says it has this ip address;
[code]em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether 00:50:c2:24:7a:df
        inet6 fe80::250:c2ff:fe24:7adf%em1 prefixlen 64 scopeid 0x2
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
[/code]

not sure what to think, could some other device on the LAN be interfering somehow?  Or is there some other service config screwing it up?  Still stumped...
thank you.</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast>

johnpoz

What is the mask on our lan interface?

You have rules that make ZERO sense at all.. If your lan IP is 192.168.1.1 with a /24 bit mask what is the point of any rules allowing access to 192.168.1.anything??

You have 3 rules that say proxied access to printing?? edit machine

Those rules would never come into play.. Do you have some sort of bridge setup?

3zzz

@johnpoz:

What is the mask on our lan interface?

You have rules that make ZERO sense at all.. If your lan IP is 192.168.1.1 with a /24 bit mask what is the point of any rules allowing access to 192.168.1.anything??

You have 3 rules that say proxied access to printing?? edit machine

Those rules would never come into play.. Do you have some sort of bridge setup?

Some of the rules you see may have been from me experimenting trying to get this to work. Other rules may be years old, I just leave well enough alone.
The isp router is in bridge mode if that's what you mean.

I modified my comment above to add more info, netmask 0xffffff00

3zzz

@johnpoz:

You have 3 rules that say proxied access to printing??

fwiw "proxied" is an alias to several LAN addresses. I don't really care about those rules unless they somehow after 6 years are preventing our web access to the LAN address.

Derelict

My money's on some other rule somewhere. Do Diagnostics > Command prompt and cat /tmp/rules.debug and send that to me in a PM.

Nothing shows up in the firewall log for these failures?

Is 192.168.1.165 listed in Diagnostics > Tables sshlockout ??

3zzz

Correct, nothing in the firewall log.
sshlockout table -> No entries exist in this table.

I'm about to go out for a few hours but I'll be back later and really appreciate your help.

Derelict

This is your problem:

LAN = "{ em1 }"

rdr on em1 proto tcp from any to 192.168.1.1 -> 192.168.1.7

Find that port forward. Actually that is probably a 1:1 NAT.

You should probably check that these are necessary and doing what you want too:

rdr on em1 proto tcp from any to 192.168.1.1 -> 192.168.1.212 port 22
rdr on em1 proto tcp from any to 192.168.1.1 port 21255 -> 192.168.1.241 port 3389

johnpoz

"I don't really care about those rules"

While your at it - might well clean up the the rest of those rules that are completely pointless. You don't care that there are rules that don't do anything?? Maybe that is part of your problem lack of understanding how the rules work?

"just leave well enough alone."

Another issue if you ask me.. What I would do after you fix this big issue is address all your rules, what do they do - are they need still do they even do anything..

"experimenting trying to get this to work"

This points to a BIG problem if you ask me.. Why would you be experimenting? You experiment on the recipe for the perfect pasta sauce or cupcake. When it comes to firewall rules there should be no experimenting.. You either understand how they work and what is needed to allow or block what you want or you don't. If you don't - that is a problem!!

In wha scenario is that 67.166.x.x address going to be both a source and or a dest address? In those first 2 rules? Your lan is 192.168 - how would there be a packet inbound to the lan interface from that IP? Dest ok maybe. But seeing that its listed as a source along with those rules to dest IPs that are in the same local lan network to allow printing??

3zzz

@Derelict:

This is your problem:

LAN = "{ em1 }"

rdr on em1 proto tcp from any to 192.168.1.1 -> 192.168.1.7

Find that port forward. Actually that is probably a 1:1 NAT.

You should probably check that these are necessary and doing what you want too:

rdr on em1 proto tcp from any to 192.168.1.1 -> 192.168.1.212 port 22
rdr on em1 proto tcp from any to 192.168.1.1 port 21255 -> 192.168.1.241 port 3389

There's only one rule involving that ip address (192.168.1.7) and it's on NAT.
It should only listen on one specific port, so not sure why it would cause the problem. Update: I deleted that rule and still can't access on the LAN address. Further update; I removed another similar rule and now I can access the LAN ip.

Those other rules are appropriate. Thank you so much for your help Derelict!

3zzz

To summarize the cause, before the move there were two upstream ISPs connected and after the move only one. Some rules that applied to the defunct ISP interface somehow got automatically converted to listening on the LAN interface, once I removed those rules the LAN interface started responding normally.

Thanks again Derelict for your help tracking this down!!!!

cheers

Derelict

somehow got automatically converted
[/sigh]

Sigh.

3zzz

@Derelict:

somehow got automatically converted

Sigh.

well they weren't changed by me, i'm not on site, if you're sighing then i imagine the guy who moved it must've done something, I'm just trying to figure it out remotely after the fact, in which I have now succeeded thanks to your help.