Getting a default denied rule after setting up the firewall rules



  • Hi all,

    Situation
    LAN –-  pfSense  --- OPT1
                            --- OPT2
                            --- OPT3

    I 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.



  • @Eugene:

    Please give us your NAT page.

    Added my NAT settings to the post above.



  • Do you use loadbalancers?



  • @Eugene:

    Do you use loadbalancers?

    Yes indeed! The 3 OPTs are combined in a loadbalancing service.



  • 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



  • @Eugene:

    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

    I 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>



  • @Eugene:

    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.



  • @Eugene:

    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 -)



  • Gonna try to connect a ubuntu machine here and try to open an external ssh session to it through pfSense.
    Results are comming over :>)



  • well here some test results:

    After connecting my 10.0.0.10 (Local device) to the modem directly all was working fine (Puts the problem definitely at the pfSense configuration)
    I did a reinstall of my pfSense machine with the 1.2.3-RC1 image and created the LoadBalacer, placed the firewall rules so the Internet was working.
    Unfortunately after creating the NAT and some more firewall rules, no connection could be made.

    I now have a modem directly connected to my local device so incoming connections bypass the pfSense firewall. Not the best way but works for now. If I find a solution in the near future I'll be sure to post it here!



  • Can you make tcpdump on local device while connected directly to modem?



  • @Eugene:

    Can you make tcpdump on local device while connected directly to modem?

    That will be very hard (The local device is a Cisco router)
    Guess I can connect my ubuntu machine directly and run a dump on there!



  • Fix it with ubuntu and then apply solution to cisco.



  • @Eugene:

    Fix it with ubuntu and then apply solution to cisco.

    just tried to do this with ubuntu.
    I'm able to connect to ubuntu over the local network (telnet and ssh)
    Applying some NAT & Firewall rules give the same result as before, no syn,ack in tcpdump, while connecting from the interwebs.

    Getting very frustrated because its lovley weather over here ;>)

    Is there a 'workaround' for natting problems like this (Like turning off the firewall completely?)

    regards from the netherlands



  • It's lovely wheather here as well (sunny, 27C) but it should not affect our ability to fix this problem. Can you post tcpdumps of your local session to this ubuntu box and remote session (through pfsense)? Both dumps from ubuntu please.



  • FINALLY!!!

    I got it to work!

    The solution:

    • I used OPT1 or OPT3 for the incoming connections, change this to WAN
    • All devices connected where configured with static IP addresses, configure for DHCP and set up DHCP-server on LAN
    • Make some NAT and firewall rules to LAN & WAN
      +> Problem solved!

    Eugene thanks for the support so far!


Log in to reply