Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Some communication from IPsec network is blocked

    2.0-RC Snapshot Feedback and Problems - RETIRED
    2
    8
    4.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rlai000
      last edited by

      I've snapshot 2.0-BETA3 built on Fri Jul 23 05:17:16 EDT 2010

      When I tried to connect to a remote site Linksys SRW2016 web interface, my browser was waiting indefinitely.  I checked the firewall logs, there are plenty of blocked entries from the switch port 80 to my computer.  The If is enc0, Proto is TCP:/TCP:A and the rule that triggered this action is @2 block drop in log all label "Default deny rule".

      I've setup all allow rule on the IPsec interface (i.e. any to any for any protocol)

      Any idea I could change the default deny rule?  Or it's a bug?

      -Raylund

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        Hitting the default rule means it didn't match any of your configured rules. Posting the full raw logs (from status.php) should help determine why (and screenshot of your rule(s) on the IPsec interface)

        1 Reply Last reply Reply Quote 0
        • R
          rlai000
          last edited by

          The attached is my rule on IPsec:

          This is the filter logs:
          Jul 25 00:32:51 pfsense pf: 00:00:00.002166 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:32:51 pfsense pf:     192.168.16.120.23 > 192.168.69.102.2987: Flags [R], cksum 0x564c (correct), seq 2749744074, win 0, length 0
          Jul 25 00:32:51 pfsense pf: 00:00:00.001123 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:32:51 pfsense pf:     192.168.16.120.515 > 192.168.69.102.2999: Flags [R], cksum 0xefe1 (correct), seq 7709712, win 0, length 0
          Jul 25 00:32:51 pfsense pf: 00:00:00.001781 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:32:51 pfsense pf:     192.168.16.120.70 > 192.168.69.102.2991: Flags [R], cksum 0x958d (correct), seq 3479129583, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:13.403416 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.37 > 192.168.69.102.3079: Flags [R], cksum 0xc737 (correct), seq 3388402606, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001381 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.143 > 192.168.69.102.3102: Flags [R], cksum 0x2b62 (correct), seq 3025058736, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002072 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.119 > 192.168.69.102.3086: Flags [R], cksum 0x7394 (correct), seq 2619774623, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002577 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.80 > 192.168.69.102.3081: Flags [R], cksum 0x71d4 (correct), seq 4103118690, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001177 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.21 > 192.168.69.102.2519: Flags [R], cksum 0x85ad (correct), seq 1439199175, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001540 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.22 > 192.168.69.102.3075: Flags [R], cksum 0xc8cb (correct), seq 2087297070, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002066 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.515 > 192.168.69.102.3103: Flags [R], cksum 0xfd68 (correct), seq 1808666858, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002378 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.7 > 192.168.69.102.2539: Flags [R], cksum 0x640a (correct), seq 4249613803, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001743 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.2210 > 192.168.69.102.3144: Flags [R], cksum 0xb188 (correct), seq 879966726, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001612 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.70 > 192.168.69.102.3080: Flags [R], cksum 0x43df (correct), seq 4285363577, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001660 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.128.23 > 192.168.69.102.3076: Flags [R], cksum 0x12c3 (correct), seq 3455609105, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.876914 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.21 > 192.168.69.102.2544: Flags [R], cksum 0x6d95 (correct), seq 3816151905, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001123 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.80 > 192.168.69.102.3169: Flags [R], cksum 0xfb84 (correct), seq 1901012249, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001578 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.515 > 192.168.69.102.3175: Flags [R], cksum 0x78b0 (correct), seq 2549826804, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002986 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.23 > 192.168.69.102.3153: Flags [R], cksum 0x0763 (correct), seq 812929356, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.000844 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.70 > 192.168.69.102.3166: Flags [R], cksum 0x7288 (correct), seq 1542571879, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002446 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.37 > 192.168.69.102.3160: Flags [R], cksum 0x9a7b (correct), seq 2102538518, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001409 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.119 > 192.168.69.102.3173: Flags [R], cksum 0x219d (correct), seq 1642304596, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001937 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.22 > 192.168.69.102.3148: Flags [R], cksum 0x2e97 (correct), seq 404485329, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001834 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.131.7 > 192.168.69.102.2567: Flags [R], cksum 0xc246 (correct), seq 4125007804, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.001829 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.143 > 192.168.69.102.3174: Flags [R], cksum 0x8e82 (correct), seq 3801519580, win 0, length 0
          Jul 25 00:33:05 pfsense pf: 00:00:00.002153 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
          Jul 25 00:33:05 pfsense pf:     192.168.16.129.2210 > 192.168.69.102.3180: Flags [R], cksum 0x5f24 (correct), seq 415356934, win 0, length 0

          ![IPsec rule.JPG](/public/imported_attachments/1/IPsec rule.JPG)
          ![IPsec rule.JPG_thumb](/public/imported_attachments/1/IPsec rule.JPG_thumb)

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Those are all RSTs from out of state traffic, nothing there would cause connectivity problems.

            1 Reply Last reply Reply Quote 0
            • R
              rlai000
              last edited by

              @cmb:

              Those are all RSTs from out of state traffic, nothing there would cause connectivity problems.

              Is it possible this causing the web interface not loading properly on my browser?

              At first I thought there is ACL on the Linksys SRW2016 switch.  But I could browser from other subnets (which have SonicWall though).  My browser just waits indefinitely.

              -Raylund

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                No, RSTs are just the close of a connection, and when they're blocked like that it's just a duplicate RST generally. Regardless dropping RSTs will never cause connectivity problems, when you're sending a RST it's closing the connection. Sounds possibly MTU related, large packets getting black holed somewhere.

                1 Reply Last reply Reply Quote 0
                • R
                  rlai000
                  last edited by

                  More information.  The previous logs didn't have the entries on the communication between SRW2016 and my computer.  Here are the logs now:

                  Jul 27 23:05:31 pfsense pf: 00:04:20.722535 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 27397, offset 0, flags [ + ], proto TCP (6), length 1436)
                  Jul 27 23:05:31 pfsense pf:     192.168.20.7.80 > 192.168.69.103.51256: Flags [.], ack 1823863771, win 3476, length 1396
                  Jul 27 23:05:31 pfsense pf: 00:00:00.000028 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 27397, offset 1416, flags [none], proto TCP (6), length 54)
                  Jul 27 23:05:31 pfsense pf:     192.168.20.7 > 192.168.69.103: tcp
                  Jul 27 23:05:31 pfsense pf: 00:00:00.001172 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 44544, offset 0, flags [ + ], proto TCP (6), length 1436)
                  Jul 27 23:05:31 pfsense pf:     192.168.20.7.80 > 192.168.69.103.51256: Flags [.], ack 1, win 3476, length 1396
                  Jul 27 23:05:31 pfsense pf: 00:00:00.000018 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 44544, offset 1416, flags [none], proto TCP (6), length 54)
                  Jul 27 23:05:31 pfsense pf:     192.168.20.7 > 192.168.69.103: tcp
                  Jul 27 23:05:33 pfsense pf: 00:00:01.968632 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 64521, offset 0, flags [ + ], proto TCP (6), length 1436)
                  Jul 27 23:05:33 pfsense pf:     192.168.20.7.80 > 192.168.69.103.51256: Flags [.], ack 1, win 3476, length 1396
                  Jul 27 23:05:33 pfsense pf: 00:00:00.000030 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 64521, offset 1416, flags [none], proto TCP (6), length 54)
                  Jul 27 23:05:33 pfsense pf:     192.168.20.7 > 192.168.69.103: tcp
                  Jul 27 23:05:37 pfsense pf: 00:00:03.958478 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 18470, offset 0, flags [ + ], proto TCP (6), length 1436)
                  Jul 27 23:05:37 pfsense pf:     192.168.20.7.80 > 192.168.69.103.51256: Flags [.], ack 1, win 3476, length 1396
                  Jul 27 23:05:37 pfsense pf: 00:00:00.000025 rule 2/0(match): block in on enc0: (tos 0x0, ttl 64, id 18470, offset 1416, flags [none], proto TCP (6), length 54)
                  Jul 27 23:05:37 pfsense pf:     192.168.20.7 > 192.168.69.103: tcp

                  I checked the MTU (using ping 192.168.20.7 -f -l 1472) and is 1500.

                  Any idea?

                  -Raylund

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    That's traffic you shouldn't see blocked, looks like possibly you have asymmetric routing, which will break stateful filtering and cause things like that. Is there another path between the two networks?

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.