SNMP UDP port 161 rule

So from not checking that it should be bound to wan and lan.. So change your wan rule to its default WAN address and not ANY. then check

the destination wan is the IP of the office where the network monitor software is at and i am still not able to see it populate.

thanks.

blocked out, but the destination is the static IP.

johnpoz

Normally on wan you would put wan address and not specific IP from the dropdown list.

But here is the thing - maybe you didn't catch my edit, canyouseeme doesn't check udp from what I can see.

@johnpoz:

Normally on wan you would put wan address and not specific IP from the dropdown list.

But here is the thing - maybe you didn't catch my edit, canyouseeme doesn't check udp from what I can see.

i think i had it with tcp/udp and tcp on its own, still nothing, but i will try again and post back.

cmb

Read the warning on the firewall rule edit page, source ports are NOT the same as destination ports and most always should be 'any'.

@tomdlgns:

@johnpoz:

So from not checking that it should be bound to wan and lan.. So change your wan rule to its default WAN address and not ANY. then check

the destination wan is the IP of the office where the network monitor software is at and i am still not able to see it populate.

thanks.

blocked out, but the destination is the static IP.

ok, made the change from my WAN IP to WAN ADDRESS and set it to TCP to see if can you see me sees that i have port 161 open and it still times out.

johnpoz

so how did you set snmp to listen on tcp? Great that you have firewall rule open for tcp 161, but that does not mean that anything is listening on tcp 161 on pfsense.

I just turned it on mine - and its not listening on tcp, only udp

udp4 0 0 192.168.1.253.161

and see cmb comments about your rule as well - source port would not be 161.

@johnpoz:

so how did you set snmp to listen on tcp? Great that you have firewall rule open for tcp 161, but that does not mean that anything is listening on tcp 161 on pfsense.

regardless if anything is listening (which it is i will explain) shouldnt canyouseeme.org show that the port is open instead of giving me an error?

not sure, maybe i am missing something?

i have a PC at my main office that is pointing to the static WAN IP of the pfsense box (PRTG Network Monitor), i assume that is what is listening for port 161. i also configured PRTG with the same SNMP settings (name, changed default to something else).

i only opened up TCP to see if can you see me sees port 161 open.

johnpoz

What is going to answer its syn if there is nothing listening - there is nothing there to connect to, so canyouseeme would give you an error.

I just verified I created a rule for telnet - nothing listening on 23

Error: I could not see your service on 24.13.xx.xx on port (23)
Reason: Connection timed out

If you rule is correct on your wan, and you show snmp listening on pfsense via netstat -an for example. And your not able to connect, do sniff on pfsense wan interface for udp 161 using tcpdump shell. Or just use the capture feature under diag, do you see the traffic to 161 – if so then you know that your isp is not blocking it. If you don't see, try a different port other than 161 that your isp would be less likely to block.

@johnpoz:

What is going to answer its syn if there is nothing listening - there is nothing there to connect to, so canyouseeme would give you an error.

I just verified I created a rule for telnet - nothing listening on 23

Error: I could not see your service on 24.13.xx.xx on port (23)
Reason: Connection timed out

If you rule is correct on your wan, and you show snmp listening on pfsense via netstat -an for example. And your not able to connect, do sniff on pfsense wan interface for udp 161 using tcpdump shell. Or just use the capture feature under diag, do you see the traffic to 161 – if so then you know that your isp is not blocking it. If you don't see, try a different port other than 161 that your isp would be less likely to block.

i appreciate the reply, but i dont understand half of your post.

bottom line, if the rule was setup properly, my PRTG network monitor would be able to see SNMP traffic on the other network, across the WAN.

that isnt happening, not sure why.

offtopic- what is the point of the canyouseeme.org website if it cant look at your WAN address and see that you have a port open? i have used that site before, with consumer routers and i have had it show me a pass/success after i opened the correct ports in the firewall.

ptt

You can use Nmap Online Scanner instead canyouseeme

Just do a "Custom Scan" with this options for custom scan:


-p 161-162 -T4 -Pn -sU 1.1.1.1

Just replace 1.1.1.1 with YOUR Public IP

johnpoz

"if the rule was setup properly, my PRTG network monitor would be able to see SNMP traffic on the other network"

Not if snmp is not really listening - did you verify with netstat pfsense that your listening on 161?
Not if ISP for wan connection pfsense is connected to blocks 161 udp

And all of your firewall rules you have posted are WRONG, the souce port would not be 161 only the dest port, source should be ANY

Your not going to allow traffic in to 161 because the source port is NOT going to be 161, it would be some random above 1024

@ptt:

You can use Nmap Online Scanner instead canyouseeme

Just do a "Custom Scan" with this options for custom scan:
-p 161-162 -T4 -Pn -sU 1.1.1.1
Just replace 1.1.1.1 with YOUR Public IP


Starting Nmap 6.01 ( http://nmap.org ) at 2012-11-16 00:53 Central Europe Standard Time
Nmap scan report for xx-xx-xx-xx-hfc.business.net (xx.xx.xx.xx)
Host is up.

looks like nmap can see it.

EDIT- ok now that i confirmed with nmap (thanks) that port 161 was open from pfsense, it only made sense that there was something with the SNMP program at the main office location.

apparently i didnt save when i changed the SNMP from default to the site specific name. once i did that, the program quickly refreshed and it showed all the pfsense interfaces almost immediately.

user error on my end.

thanks for posting nmap, that confirmed the correct ports were open. also, i changed the firewall rule as you suggested.

thank you.