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

    VPN ok, but no traffic on it…

    Scheduled Pinned Locked Moved IPsec
    20 Posts 2 Posters 14.4k Views
    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.
    • P
      psylo
      last edited by

      Hello,

      What do you call remote interface?

      Can you make a quick draw explaining where you see icmp packet and where you don't?

      1 Reply Last reply Reply Quote 0
      • S
        sap68
        last edited by

        @psylo:

        Hello,

        What do you call remote interface?

        Can you make a quick draw explaining where you see icmp packet and where you don't?

        It's a simple point-to-point VPN

        Office1 LAN: 192.168.50.0/24 -> pfsense (192.168.50.1/publIP)
        Office2 LAN: 172.16.120.0/24 -> netasq (172.16.120.1/publIP)

        The configuration of tunnel I'm sure it's ok, because the tunnel goes ON (see image attached):

        Anyway, I was wrong about ping: when from my LAN (192.168.50.0) try to ping remote private ip of netasq (172.16.120.1), the packet is recognised by netasq, in fact if I dump the IPSec interface this is the resul of my ping:

        
        U120XA0A0804150>tcpdump -ni enc0
        tcpdump: WARNING: enc0: no IPv4 address assigned
        tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
        listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 96 bytes
        09:49:12.598323 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 0, length 64
        09:49:13.599303 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 1, length 64
        09:49:14.599476 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 2, length 64
        09:49:15.598345 (authentic,confidential): SPI 0x08641654: IP 192.168.50.198 > 172.16.120.1: ICMP echo request, id 17957, seq 3, length 64
        
        

        On Netasq I open a firewall rule that pass all on IPSec interface, but I have another 3 VPN on that netasq that work perfectly and I replicate the rules for this one…

        ![Schermata 2011-02-19 a 09.34.55.png](/public/imported_attachments/1/Schermata 2011-02-19 a 09.34.55.png)
        ![Schermata 2011-02-19 a 09.34.55.png_thumb](/public/imported_attachments/1/Schermata 2011-02-19 a 09.34.55.png_thumb)

        1 Reply Last reply Reply Quote 0
        • P
          psylo
          last edited by

          First, can you ping anything else than Netasq interface. When doing that, can you dump on interface in of the Netasq?

          1 Reply Last reply Reply Quote 0
          • S
            sap68
            last edited by

            @psylo:

            First, can you ping anything else than Netasq interface. When doing that, can you dump on interface in of the Netasq?

            I try to ping another Lan host (172.16.120.71) and dump IN interface of netasq (172.16.120.1):

            tcpdump -ni eth0 host (Pfsense PublicIP) and icmp

            But i see no packet.

            1 Reply Last reply Reply Quote 0
            • P
              psylo
              last edited by

              If you dump on interface in, you'll normally see "deencapsulated" traffic and thus the source IP is the LAN IP (192.168.50.198).

              1 Reply Last reply Reply Quote 0
              • S
                sap68
                last edited by

                @psylo:

                If you dump on interface in, you'll normally see "deencapsulated" traffic and thus the source IP is the LAN IP (192.168.50.198).

                You're right, but i have no luck :-/

                
                U120XA0A0804150>tcpdump -ni eth0 host 192.168.50.198 and icmp
                tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
                0 packets captured
                2637 packets received by filter
                0 packets dropped by kernel
                
                
                1 Reply Last reply Reply Quote 0
                • P
                  psylo
                  last edited by

                  Ok. So, nothing appears on the LAN interface. So, it should be a firewalling problem… Do you have any rule which permits traffic from your LAN to the Netasq LAN?

                  Last, I suppose there is no route for the range 192.168.50.x on the Netasq. I mean: this range is not known by the Netasq except for your IPSEC tunnel.

                  1 Reply Last reply Reply Quote 0
                  • S
                    sap68
                    last edited by

                    @psylo:

                    Ok. So, nothing appears on the LAN interface. So, it should be a firewalling problem… Do you have any rule which permits traffic from your LAN to the Netasq LAN?

                    Last, I suppose there is no route for the range 192.168.50.x on the Netasq. I mean: this range is not known by the Netasq except for your IPSEC tunnel.

                    I have a rule that passAll on IPSec interface from any -> "networks internals" (LAN range)
                    Do you think it's necessary a static route for 192.168.50.x range?
                    Thank again for your help!

                    1 Reply Last reply Reply Quote 0
                    • P
                      psylo
                      last edited by

                      You don't need to add a route except if the IPsec is configured to "consider IPsec peer as internal". If IPsec is configured like that, you need to add a static route pointing to interface IPsec.

                      By the way, can you send a screenshot of the firewall rules on the Netasq?

                      I'll be unavailable for 1 hour.

                      1 Reply Last reply Reply Quote 0
                      • S
                        sap68
                        last edited by

                        @psylo:

                        You don't need to add a route except if the IPsec is configured to "consider IPsec peer as internal". If IPsec is configured like that, you need to add a static route pointing to interface IPsec.

                        By the way, can you send a screenshot of the firewall rules on the Netasq?

                        I'll be unavailable for 1 hour.

                        Ok, thanks!

                        This are the first 15 rules…

                        Rule number 12 it's this VPN.
                        Rule from 5 to 11 it's others (worked!) VPN...

                        ![Schermata 2011-02-19 a 10.50.42.png_thumb](/public/imported_attachments/1/Schermata 2011-02-19 a 10.50.42.png_thumb)
                        ![Schermata 2011-02-19 a 10.50.42.png](/public/imported_attachments/1/Schermata 2011-02-19 a 10.50.42.png)

                        1 Reply Last reply Reply Quote 0
                        • P
                          psylo
                          last edited by

                          Ok… The point is that you need to be authenticated on the Netasq before your traffic is allowed. This is the @ in the source column...

                          So, either you change that to get rid of the authentication. Either you authenticate yourself on the Netasq web interface...

                          Well, as we speak about IPSec tunnel, I strongly recommend to disable the authentication for those traffic (as traffics are already trusted).

                          1 Reply Last reply Reply Quote 0
                          • S
                            sap68
                            last edited by

                            @psylo:

                            Ok… The point is that you need to be authenticated on the Netasq before your traffic is allowed. This is the @ in the source column...

                            So, either you change that to get rid of the authentication. Either you authenticate yourself on the Netasq web interface...

                            Well, as we speak about IPSec tunnel, I strongly recommend to disable the authentication for those traffic (as traffics are already trusted).

                            Oh YES!
                            That work!

                            The problem is in the rule 12, I modify the rule so I permit traffic from 192.168.50.0 to Networks internal and now it worked!!!

                            MANY THANKS guys!

                            1 Reply Last reply Reply Quote 0
                            • P
                              psylo
                              last edited by

                              Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

                              • disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

                              • use network object (as you've done for your tunnel) for each tunnel…

                              1 Reply Last reply Reply Quote 0
                              • S
                                sap68
                                last edited by

                                @psylo:

                                Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

                                • disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

                                • use network object (as you've done for your tunnel) for each tunnel…

                                Disable auth.: I must disabled auth. also for IPsec mobile connection?

                                Thanks…

                                1 Reply Last reply Reply Quote 0
                                • P
                                  psylo
                                  last edited by

                                  @sap68:

                                  @psylo:

                                  Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

                                  • disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

                                  • use network object (as you've done for your tunnel) for each tunnel…

                                  Disable auth.: I must disabled auth. also for IPsec mobile connection?

                                  Thanks…

                                  Well… Actually, I don't know why you use Authentication for VPN tunnel (rules 5 to 11)... Normally, It's not necessary... But If you do that, you'll need to configure network objects defining all your remote networks in order to avoir security holes... Do you see what I mean?

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sap68
                                    last edited by

                                    @psylo:

                                    @sap68:

                                    @psylo:

                                    Great news but as said in my previous post, I strongly recommends 2 things for IPSec filtering:

                                    • disable authentication for IPSec tunnel as those traffic are already trusted. Except if you need authentication for HTTP proxy for example.

                                    • use network object (as you've done for your tunnel) for each tunnel…

                                    Disable auth.: I must disabled auth. also for IPsec mobile connection?

                                    Thanks…

                                    Well… Actually, I don't know why you use Authentication for VPN tunnel (rules 5 to 11)... Normally, It's not necessary... But If you do that, you'll need to configure network objects defining all your remote networks in order to avoir security holes... Do you see what I mean?

                                    Yes, I understand.

                                    I use this particular configuration (made with netasq support) for consent access from outside for some customer that needed access on particular server inside LAN.
                                    Authentication VPN from <<any>> host it's (i think) only method to obtain the goal.
                                    In particular I have a rule for every mobile access and i pass all traffic only to a host.

                                    In you opinion it is a flaw in security?

                                    Thanks…</any>

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      psylo
                                      last edited by

                                      Ok… You're in an exception and this is not a security hole.
                                      If you use only "any" as source, it could be a security hole but not with authentication.

                                      BTW, good news your tunnel is working.

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