Getting a default denied rule after setting up the firewall rules
-
Hi all,
Situation
LAN –- pfSense --- OPT1
--- OPT2
--- OPT3I want to be able to open a telnet session to the computer on the LAN network (with static IP) from the internet through the OPT3 interface.
But I'm getting a default denied error after I made some firewall and NAT settings:
Its getting in as we can see, but the connection is not allowed to talk back????My OPT3 firewall rules (That works as we can see above):
My LAN firewall rules (That strangely doesn't work):
- I tried to set the gateway on the LAN firewall rule to default, but didn't work.
- I tried to change the source in the LAN firewall rule to LAN Subnet, but no luck.
Has any body got an idea what I'm missing to get this to work?
Best regards,
Tim -
Please give us your NAT page.
-
-
Do you use loadbalancers?
-
-
try to create a rule on the top of your rules on LAN interface:
allow any from 10.0.0.10 to 99.199.45.221 any gateway=OPT3 -
try to create a rule on the top of your rules on LAN interface:
allow any from 10.0.0.10 to 99.199.45.221 any gateway=OPT3I think I already did, see the LAN firewall settings in my first post (last image)
-
Have you done packet trace on all 'public' interfaces? kind of
tcpdump -ni <opt1>host 99.199.45.221
I suspect that your traffic is routed back through srong interface… I might be wrong.</opt1> -
Have you done packet trace on all 'public' interfaces? kind of
tcpdump -ni <opt1>host 99.199.45.221
I suspect that your traffic is routed back through srong interface… I might be wrong.</opt1>I'm gonna give it a try in 10 minutes, but the firewall logs show that the LAN interface is blocking, therefore I think this is not the problem.
-
and please try to catch states during your session
pfctl -ss | grep 99.199.45.221 -
Got some detailed information here:
The tcpdump shows that its comming in over OPT3(re3) and is leaving over LAN(em0)
# tcpdump -ni re3 host 91.199.45.221 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re3, link-type EN10MB (Ethernet), capture size 96 bytes 18:58:44.729579 IP 10.0.30.254.62553 > 91.199.45.221.2121: P 777542828:777542880(52) ack 2007138495 win 256 18:58:44.767884 IP 91.199.45.221.2121 > 10.0.30.254.62553: P 1:69(68) ack 52 win 142 18:58:44.938819 IP 10.0.30.254.62553 > 91.199.45.221.2121: P 52:104(52) ack 69 win 255 18:58:44.976814 IP 91.199.45.221.2121 > 10.0.30.254.62553: P 69:121(52) ack 104 win 142 18:58:44.992309 IP 91.199.45.221.2121 > 10.0.30.254.62553: P 121:189(68) ack 104 win 142 18:58:44.993159 IP 10.0.30.254.62553 > 91.199.45.221.2121: . ack 189 win 255 18:58:44.993204 IP 91.199.45.221.60954 > 10.0.30.254.23: S 3624875656:3624875656(0) win 5840 <mss 6="" 1899518575="" 1460,sackok,timestamp="" 0,nop,wscale="">18:58:47.992676 IP 91.199.45.221.60954 > 10.0.30.254.23: S 3624875656:3624875656(0) win 5840 <mss 6="" 1899519325="" 1460,sackok,timestamp="" 0,nop,wscale="">18:58:53.992731 IP 91.199.45.221.60954 > 10.0.30.254.23: S 3624875656:3624875656(0) win 5840 <mss 6="" 1899520825="" 1460,sackok,timestamp="" 0,nop,wscale="">18:59:05.992463 IP 91.199.45.221.60954 > 10.0.30.254.23: S 3624875656:3624875656(0) win 5840</mss></mss></mss># tcpdump -ni em0 host 91.199.45.221 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 18:59:24.676558 IP 10.0.0.10.49403 > 91.199.45.221.2121: P 777542932:777542984(52) ack 2007138683 win 255 18:59:24.716246 IP 91.199.45.221.2121 > 10.0.0.10.49403: P 1:85(84) ack 52 win 142 18:59:24.716261 IP 91.199.45.221.2121 > 10.0.0.10.49403: P 85:153(68) ack 52 win 142 18:59:24.717408 IP 10.0.0.10.49403 > 91.199.45.221.2121: . ack 153 win 254 18:59:25.369123 IP 10.0.0.10.49403 > 91.199.45.221.2121: P 52:104(52) ack 153 win 254 18:59:25.407223 IP 91.199.45.221.2121 > 10.0.0.10.49403: P 153:221(68) ack 104 win 142 18:59:25.607598 IP 10.0.0.10.49403 > 91.199.45.221.2121: P 104:156(52) ack 221 win 254 18:59:25.645676 IP 91.199.45.221.2121 > 10.0.0.10.49403: P 221:273(52) ack 156 win 142 18:59:25.661707 IP 91.199.45.221.2121 > 10.0.0.10.49403: P 273:341(68) ack 156 win 142 18:59:25.661775 IP 91.199.45.221.43367 > 10.0.0.10.23: S 3684512266:3684512266(0) win 5840 <mss 6="" 1899528742="" 1460,sackok,timestamp="" 0,nop,wscale="">18:59:25.662563 IP 10.0.0.10.49403 > 91.199.45.221.2121: . ack 341 win 253 18:59:25.665811 IP 10.0.0.10.8 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128 <mss 536="">18:59:27.667055 IP 10.0.0.10.1 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128 <mss 536="">18:59:28.660593 IP 91.199.45.221.43367 > 10.0.0.10.23: S 3684512266:3684512266(0) win 5840 <mss 6="" 1899529492="" 1460,sackok,timestamp="" 0,nop,wscale="">18:59:28.662051 IP 10.0.0.10.8 > 91.199.45.221.43367: . ack 1 win 4128 18:59:31.667660 IP 10.0.0.10.1 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128</mss></mss></mss></mss>And the pf gives me:
# pfctl -ss | grep 91.199.45.221 all tcp 91.199.45.221:2121 <- 10.0.0.10:49403 ESTABLISHED:ESTABLISHED all tcp 10.0.0.10:49403 -> 10.0.30.254:62553 -> 91.199.45.221:2121 ESTABLISHED:ESTABLISHED all tcp 10.0.0.10:23 <- 10.0.30.254:23 <- 91.199.45.221:60951 CLOSED:SYN_SENT all tcp 91.199.45.221:60951 -> 10.0.0.10:23 SYN_SENT:CLOSED all tcp 10.0.0.10:23 <- 10.0.30.254:23 <- 91.199.45.221:60954 CLOSED:SYN_SENT all tcp 91.199.45.221:60954 -> 10.0.0.10:23 SYN_SENT:CLOSED all tcp 10.0.0.10:23 <- 10.0.30.254:23 <- 91.199.45.221:43367 CLOSED:SYN_SENT all tcp 91.199.45.221:43367 -> 10.0.0.10:23 SYN_SENT:CLOSED -
# tcpdump -ni em0 host 91.199.45.221 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes ... 18:59:25.661775 IP 91.199.45.221.43367 > 10.0.0.10.23: S 3684512266:3684512266(0) win 5840 <mss 6="" 1899528742="" 1460,sackok,timestamp="" 0,nop,wscale="">18:59:25.662563 IP 10.0.0.10.49403 > 91.199.45.221.2121: . ack 341 win 253 18:59:25.665811 IP 10.0.0.10.8 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128 <mss 536="">18:59:27.667055 IP 10.0.0.10.1 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128 <mss 536="">18:59:28.660593 IP 91.199.45.221.43367 > 10.0.0.10.23: S 3684512266:3684512266(0) win 5840 <mss 6="" 1899529492="" 1460,sackok,timestamp="" 0,nop,wscale="">18:59:28.662051 IP 10.0.0.10.8 > 91.199.45.221.43367: . ack 1 win 4128 18:59:31.667660 IP 10.0.0.10.1 > 91.199.45.221.43367: S 4157337059:4157337059(0) ack 3684512267 win 4128</mss></mss></mss></mss>I can't see your 10.0.0.10 responding with syn,ack. Can you? So, it does not accept tcp-connection at port 23.
-
Hmmm…
Fact is that the 10.0.0.10 device is trying to reply to the telnet session because:
- I can connect from inside the lan locally to this device;
- The LAN firewall rules are picking up a reply generated by the telnet session trying to connect (See 2nd image in first post)
-
pfSense does not see syn,ack, it means your 10.0.0.10 does not route 91.199.45.221 back to pfSense.
-
pfSense does not see syn,ack, it means your 10.0.0.10 does not route 91.199.45.221 back to pfSense.
Thanks for the help so far by the way!
But 'unfortunately' the 10.0.0.10 can connect to this ip using http
-
I think it would be more clear if you could tcpdump on 10.0.0.10 to see whether it responds to IP 91.199.45.221.43367 > 10.0.0.10.23: S
Can you? -
Sure I can check this:
# tcpdump -ni em0 | grep 91.199.45.221 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 22:12:57.604130 IP 91.199.45.221.34002 > 10.0.0.10.23: S 3047972562:3047972562(0) win 5840 <mss 6="" 1902431548="" 1460,sackok,timestamp="" 0,nop,wscale="">22:12:57.607788 IP 10.0.0.10.18 > 91.199.45.221.34002: S 564746040:564746040(0) ack 3047972563 win 4128 <mss 536="">22:12:59.608156 IP 10.0.0.10.1 > 91.199.45.221.34002: S 564746040:564746040(0) ack 3047972563 win 4128 <mss 536="">22:13:00.606330 IP 91.199.45.221.34002 > 10.0.0.10.23: S 3047972562:3047972562(0) win 5840 <mss 6="" 1902432298="" 1460,sackok,timestamp="" 0,nop,wscale="">22:13:00.607776 IP 10.0.0.10.18 > 91.199.45.221.34002: . ack 1 win 4128 22:13:03.608388 IP 10.0.0.10.1 > 91.199.45.221.34002: S 564746040:564746040(0) ack 3047972563 win 4128 <mss 536="">22:13:06.606098 IP 91.199.45.221.34002 > 10.0.0.10.23: S 3047972562:3047972562(0) win 5840 <mss 6="" 1902433798="" 1460,sackok,timestamp="" 0,nop,wscale="">22:13:06.607501 IP 10.0.0.10.18 > 91.199.45.221.34002: . ack 1 win 4128 22:13:11.608230 IP 10.0.0.10.1 > 91.199.45.221.34002: S 564746040:564746040(0) ack 3047972563 win 4128 <mss 536="">22:13:18.605858 IP 91.199.45.221.34002 > 10.0.0.10.23: S 3047972562:3047972562(0) win 5840 <mss 6="" 1902436798="" 1460,sackok,timestamp="" 0,nop,wscale="">22:13:18.607577 IP 10.0.0.10.18 > 91.199.45.221.34002: . ack 1 win 4128</mss></mss></mss></mss></mss></mss></mss></mss>And the firewall messages:
Might it have something to do that I'm using the loadbalacing service?
-
If you think this```
22:12:57.604130 IP 91.199.45.221.34002 > 10.0.0.10.23: S 3047972562:3047972562(0) win 5840 <mss 6="" 1902431548="" 1460,sackok,timestamp="" 0,nop,wscale="">22:12:57.607788 IP 10.0.0.10.18 > 91.199.45.221.34002: S 564746040:564746040(0) ack 3047972563 win 4128</mss>is correct then you are probably wrong. Why you have in source 10.0.0.10.18 instead of 10.0.0.10.23 ??? I am confused… -
I haven't got the slithest idea what it could be.
I'm thinking of a reinstall with only 1WAN and then try to NAT something.I'll let you know tomorrow (11 PM over here already)
-
I would blame 10.0.0.10 here.
Make local connection with network dumps.
… or good night -)
