Netgate Store

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lifeboy

Pages: [1] 2
1
IPsec / Re: IPSec traffic stops, no errors, but link stays up
« on: April 19, 2018, 07:17:54 am »
Check the other side and verify all the settings match. Verify the phase two ID's match.

The connection is established and stays established for phase 1 and 2.  If there was a mismatch, they wouldn't connect to begin with.  I have checked both sides many times and everything matches.

The link stays up, but if nothing is done over it, something happens that puts the link into a state where no traffic traverses over it.  Then, by attempting to connect to a database service on the other end, the link is woken up after about 30 - 60 seconds.

2
IPsec / Re: IPSec traffic stops, no errors, but link stays up
« on: April 18, 2018, 11:07:10 am »
What can I do the try to troubleshoot this?  If the logs don't show anything, I'm pretty much stumped, aren't I?

3
IPsec / IPSec traffic stops, no errors, but link stays up
« on: April 17, 2018, 06:48:17 am »
I have a strange issue between 2 pfSense servers.  One is for production and the other a development environment.  We link the two via IPSec.

In the period of the log attached the connection is up, but I am not able to connect to a host on the "other" end.

From /var/etc/ipsec/ipsec.conf

conn con4000
   fragmentation = yes
   keyexchange = ikev1
   reauth = yes
   forceencaps = no
   mobike = no
   
   rekey = yes
   installpolicy = yes
   type = tunnel
   dpdaction = restart
   dpddelay = 1s
   dpdtimeout = 3s
   auto = route
   left = 129.232.232.130
   right = 196.30.52.140
   leftid = 129.232.232.130
   ikelifetime = 604800s
   lifetime = 3600s
   ike = aes256-sha1-modp1024!
   esp = aes256-sha1-modp1024!
   leftauth = psk
   rightauth = psk
   rightid = 196.30.52.140
   aggressive = no
   rightsubnet = 196.30.30.98
   leftsubnet = 41.75.111.176|192.168.0.22

# Options for the charon IKE daemon.
charon {

    # Accept unencrypted ID and HASH payloads in IKEv1 Main Mode.
    # accept_unencrypted_mainmode_messages = no

    # Maximum number of half-open IKE_SAs for a single peer IP.
    # block_threshold = 5

    # Whether Certicate Revocation Lists (CRLs) fetched via HTTP or LDAP should
    # be saved under a unique file name derived from the public key of the
    # Certification Authority (CA) to /etc/ipsec.d/crls (stroke) or
    # /etc/swanctl/x509crl (vici), respectively.
    # cache_crls = no

    # Whether relations in validated certificate chains should be cached in
    # memory.
    # cert_cache = yes

    # Send Cisco Unity vendor ID payload (IKEv1 only).
    # cisco_unity = no

    # Close the IKE_SA if setup of the CHILD_SA along with IKE_AUTH failed.
    # close_ike_on_child_failure = no

    # Number of half-open IKE_SAs that activate the cookie mechanism.
    # cookie_threshold = 10

    # Delete CHILD_SAs right after they got successfully rekeyed (IKEv1 only).
    # delete_rekeyed = no

    # Delay in seconds until inbound IPsec SAs are deleted after rekeyings
    # (IKEv2 only).
    # delete_rekeyed_delay = 5

    # Use ANSI X9.42 DH exponent size or optimum size matched to cryptographic
    # strength.
    # dh_exponent_ansi_x9_42 = yes

    # Use RTLD_NOW with dlopen when loading plugins and IMV/IMCs to reveal
    # missing symbols immediately.
    # dlopen_use_rtld_now = no

    # DNS server assigned to peer via configuration payload (CP).
    # dns1 =

    # DNS server assigned to peer via configuration payload (CP).
    # dns2 =

    # Enable Denial of Service protection using cookies and aggressiveness
    # checks.
    # dos_protection = yes

    # Compliance with the errata for RFC 4753.
    # ecp_x_coordinate_only = yes

    # Free objects during authentication (might conflict with plugins).
    # flush_auth_cfg = no

    # Whether to follow IKEv2 redirects (RFC 5685).
    # follow_redirects = yes

    # Maximum size (complete IP datagram size in bytes) of a sent IKE fragment
    # when using proprietary IKEv1 or standardized IKEv2 fragmentation, defaults
    # to 1280 (use 0 for address family specific default values, which uses a
    # lower value for IPv4).  If specified this limit is used for both IPv4 and
    # IPv6.
    # fragment_size = 1280

    # Name of the group the daemon changes to after startup.
    # group =

    # Timeout in seconds for connecting IKE_SAs (also see IKE_SA_INIT DROPPING).
    # half_open_timeout = 30

    # Enable hash and URL support.
    # hash_and_url = no

    # Allow IKEv1 Aggressive Mode with pre-shared keys as responder.
    # i_dont_care_about_security_and_use_aggressive_mode_psk = no

    # Whether to ignore the traffic selectors from the kernel's acquire events
    # for IKEv2 connections (they are not used for IKEv1).
    # ignore_acquire_ts = no

    # A space-separated list of routing tables to be excluded from route
    # lookups.
    # ignore_routing_tables =

    # Maximum number of IKE_SAs that can be established at the same time before
    # new connection attempts are blocked.
    # ikesa_limit = 0

    # Number of exclusively locked segments in the hash table.
    # ikesa_table_segments = 1

    # Size of the IKE_SA hash table.
    # ikesa_table_size = 1

    # Whether to close IKE_SA if the only CHILD_SA closed due to inactivity.
    # inactivity_close_ike = no

    # Limit new connections based on the current number of half open IKE_SAs,
    # see IKE_SA_INIT DROPPING in strongswan.conf(5).
    # init_limit_half_open = 0

    # Limit new connections based on the number of queued jobs.
    # init_limit_job_load = 0

    # Causes charon daemon to ignore IKE initiation requests.
    # initiator_only = no

    # Install routes into a separate routing table for established IPsec
    # tunnels.
    # install_routes = yes

    # Install virtual IP addresses.
    # install_virtual_ip = yes

    # The name of the interface on which virtual IP addresses should be
    # installed.
    # install_virtual_ip_on =

    # Check daemon, libstrongswan and plugin integrity at startup.
    # integrity_test = no

    # A comma-separated list of network interfaces that should be ignored, if
    # interfaces_use is specified this option has no effect.
    # interfaces_ignore =

    # A comma-separated list of network interfaces that should be used by
    # charon. All other interfaces are ignored.
    # interfaces_use =

    # NAT keep alive interval.
    # keep_alive = 20s

    # Plugins to load in the IKE daemon charon.
    # load =

    # Determine plugins to load via each plugin's load option.
    # load_modular = no

    # Initiate IKEv2 reauthentication with a make-before-break scheme.
    # make_before_break = no

    # Maximum number of IKEv1 phase 2 exchanges per IKE_SA to keep state about
    # and track concurrently.
    # max_ikev1_exchanges = 3

    # Maximum packet size accepted by charon.
    # max_packet = 10000

    # Enable multiple authentication exchanges (RFC 4739).
    # multiple_authentication = yes

    # WINS servers assigned to peer via configuration payload (CP).
    # nbns1 =

    # WINS servers assigned to peer via configuration payload (CP).
    # nbns2 =

    # UDP port used locally. If set to 0 a random port will be allocated.
    # port = 500

    # UDP port used locally in case of NAT-T. If set to 0 a random port will be
    # allocated.  Has to be different from charon.port, otherwise a random port
    # will be allocated.
    # port_nat_t = 4500

    # Whether to prefer updating SAs to the path with the best route.
    # prefer_best_path = no

    # Prefer locally configured proposals for IKE/IPsec over supplied ones as
    # responder (disabling this can avoid keying retries due to
    # INVALID_KE_PAYLOAD notifies).
    # prefer_configured_proposals = yes

    # By default public IPv6 addresses are preferred over temporary ones (RFC
    # 4941), to make connections more stable. Enable this option to reverse
    # this.
    # prefer_temporary_addrs = no

    # Process RTM_NEWROUTE and RTM_DELROUTE events.
    # process_route = yes

    # Delay in ms for receiving packets, to simulate larger RTT.
    # receive_delay = 0

    # Delay request messages.
    # receive_delay_request = yes

    # Delay response messages.
    # receive_delay_response = yes

    # Specific IKEv2 message type to delay, 0 for any.
    # receive_delay_type = 0

    # Size of the AH/ESP replay window, in packets.
    # replay_window = 32

    # Base to use for calculating exponential back off, see IKEv2 RETRANSMISSION
    # in strongswan.conf(5).
    # retransmit_base = 1.8

    # Maximum jitter in percent to apply randomly to calculated retransmission
    # timeout (0 to disable).
    # retransmit_jitter = 0

    # Upper limit in seconds for calculated retransmission timeout (0 to
    # disable).
    # retransmit_limit = 0

    # Timeout in seconds before sending first retransmit.
    # retransmit_timeout = 4.0

    # Number of times to retransmit a packet before giving up.
    # retransmit_tries = 5

    # Interval in seconds to use when retrying to initiate an IKE_SA (e.g. if
    # DNS resolution failed), 0 to disable retries.
    # retry_initiate_interval = 0

    # Initiate CHILD_SA within existing IKE_SAs (always enabled for IKEv1).
    # reuse_ikesa = yes

    # Numerical routing table to install routes to.
    # routing_table =

    # Priority of the routing table.
    # routing_table_prio =

    # Delay in ms for sending packets, to simulate larger RTT.
    # send_delay = 0

    # Delay request messages.
    # send_delay_request = yes

    # Delay response messages.
    # send_delay_response = yes

    # Specific IKEv2 message type to delay, 0 for any.
    # send_delay_type = 0

    # Send strongSwan vendor ID payload
    # send_vendor_id = no

    # Whether to enable Signature Authentication as per RFC 7427.
    # signature_authentication = yes

    # Whether to enable constraints against IKEv2 signature schemes.
    # signature_authentication_constraints = yes

    # The upper limit for SPIs requested from the kernel for IPsec SAs.
    # spi_max = 0xcfffffff

    # The lower limit for SPIs requested from the kernel for IPsec SAs.
    # spi_min = 0xc0000000

    # Number of worker threads in charon.
    # threads = 16

    # Name of the user the daemon changes to after startup.
    # user =

    crypto_test {

        # Benchmark crypto algorithms and order them by efficiency.
        # bench = no

        # Buffer size used for crypto benchmark.
        # bench_size = 1024

        # Number of iterations to test each algorithm.
        # bench_time = 50

        # Test crypto algorithms during registration (requires test vectors
        # provided by the test-vectors plugin).
        # on_add = no

        # Test crypto algorithms on each crypto primitive instantiation.
        # on_create = no

        # Strictly require at least one test vector to enable an algorithm.
        # required = no

        # Whether to test RNG with TRUE quality; requires a lot of entropy.
        # rng_true = no

    }

    host_resolver {

        # Maximum number of concurrent resolver threads (they are terminated if
        # unused).
        # max_threads = 3

        # Minimum number of resolver threads to keep around.
        # min_threads = 0

    }

    leak_detective {

        # Includes source file names and line numbers in leak detective output.
        # detailed = yes

        # Threshold in bytes for leaks to be reported (0 to report all).
        # usage_threshold = 10240

        # Threshold in number of allocations for leaks to be reported (0 to
        # report all).
        # usage_threshold_count = 0

    }

    processor {

        # Section to configure the number of reserved threads per priority class
        # see JOB PRIORITY MANAGEMENT in strongswan.conf(5).
        priority_threads {

        }

    }

    # Section containing a list of scripts (name = path) that are executed when
    # the daemon is started.
    start-scripts {

    }

    # Section containing a list of scripts (name = path) that are executed when
    # the daemon is terminated.
    stop-scripts {

    }

    tls {

        # List of TLS encryption ciphers.
        # cipher =

        # List of TLS key exchange methods.
        # key_exchange =

        # List of TLS MAC algorithms.
        # mac =

        # List of TLS cipher suites.
        # suites =

    }

    x509 {

        # Discard certificates with unsupported or unknown critical extensions.
        # enforce_critical = yes

    }

}



4
IPsec / Re: IPSec VPN with native windows VPN client
« on: March 01, 2018, 02:12:55 am »

What causes this insertion and how to we stop that from happening?


Oh, how the sneaky obscure windows settings snag the occasional visitor to it's strange entangled world! :-)

I thought I found the problem, but no! The Windows client had the "use default gateway on remote network" set in the VPN client (tcp/ip properties | advanced).  Unchecked that and that causes the additional default route insertion to stop, but it also doesn't know how to route any traffic via the VPN. 

So do I have to add a manual route to the IPSec client config?  I will do that for now, but I have a hunch that the IPSec server should somehow tell the client what traffic to route via it, not?

5
IPsec / Re: IPSec VPN with native windows VPN client
« on: March 01, 2018, 02:05:36 am »
At the moment I'd say your best bet is this: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

This works well from the latest Windows 10 clients (Version 10.0.16299 Build 16299), but there is a problem that sneaks in.

The IPSec connection also add a default route to the windows routing table resulting in 2 0.0.0.0 routes.  This breaks internet access.

What causes this insertion and how to we stop that from happening?

Here are the routes:

Code: [Select]
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.43.1   192.168.43.218   4280
          0.0.0.0          0.0.0.0         On-link     192.168.120.1     46

thanks!

6
IPsec / IPSec phase2 with NAT/BINAT both sides fails to communicate
« on: February 09, 2018, 06:03:41 pm »
When I set up an IPSec tunnel with phase2 using NAT/BINAT, communication to the NAT'ed side stops.

When I remote the NAT/BINAT, all is well. 

I have read https://forum.pfsense.org/index.php?topic=132486.0 which seems quite similar, except that my far side is not Azure, but another of pfSense box that I have control over. 

Of course, if this was my "live" setup, I could just not use NAT, but in the final setup, I need to connect to a service provider who doesn't allow us to do comms over private ip addresses.

Has anyone run into this and how did you fix it?

7
DHCP and DNS / Re: Alias resolution somewhat cripple
« on: September 19, 2017, 03:26:08 pm »
Thanks for your responses! 

I rechecked the aliases vs the results of a dig / drill of the name and it does indeed add all the addresses correctly.  I had quite some problems with this in the past, but I never really figured out how I could check the resolution.  I didn't know about diagnostics | tables.


8
DHCP and DNS / Alias resolution somewhat cripple
« on: September 12, 2017, 08:34:37 am »
I have noticed this before and would like to see if something can be done about this.

When an alias is added to pfSense, it seems that the name gets randomly resolved if there's more than one A record.  An example:

Code: [Select]
$ dig  httpredir.debian.org

; <<>> DiG 9.10.3-P4-Ubuntu <<>> httpredir.debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15753
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;httpredir.debian.org. IN A

;; ANSWER SECTION:
httpredir.debian.org. 3464 IN CNAME static.debian.org.
static.debian.org. 164 IN A 5.153.231.4
static.debian.org. 164 IN A 149.20.4.15
static.debian.org. 164 IN A 130.89.148.14
static.debian.org. 164 IN A 128.31.0.62

;; Query time: 6 msec
;; SERVER: 192.168.121.1#53(192.168.121.1)
;; WHEN: Tue Sep 12 15:12:00 SAST 2017
;; MSG SIZE  rcvd: 144

So if I add httpredir.debian.org, it doesn't work most of the time in a firewall rule and I have to manually add each ip address to the alias to get the desired result.

If would be really beneficial if a simple lookup could be done when a name (instead of an ip) is added to an alias and the appropriate records added.  Then one could have a refresh of the name (manually) or at startup or some other event to refresh records that have changed.

Mikrotik RouterOS has such a capability when one creates firewall address-lists.  You enter the name and the system resolves the records and add one or more to the list as may be required.  This really makes life so much easier.

Is something like this is the works or could it be added to a list of feature to be expanded?

thanks and regards

Roland

9
Since a recent upgrade (I'm on 2.3.2_1 now), in many places in the GUI virtually only a-z, A-Z, 0-9 seem to be allowed.  Previously this was not the case.  Now I can't even use an _ in an alias name for instance.  Or an @ or $ in a password.  While it is possible to use simpler strings, specifically in the instance of passwords, this significantly reduces the security of a password.  Strangely enough, anything already stored in a config somewhere continues to be accepted, it's only new passwords and other entries that are not allowed to have even the simplest special characters.

I suppose this is a bug, since I cannot believe that this is a design decision or is it?

An example:
Setting a L2TP user's password which includes a @, results in this:
The password contains invalid characters.

What's going on here?

thanks

10
I have a curious problem.  A perfectly working pfSense KVM machine (configured as per my post here: https://forum.pfsense.org/index.php?topic=88858.msg491311#msg491311 ), has the following symptoms now.
  • I have two bridges on the host machine: vmbr0 (LAN) and vmbr1 (WAN).   Both have tx checksumming turned off.
  • When I start the VM guest with pfSense, I cannot communicate with it via the WAN or LAN port.  All I can do is see via the KVM (proxmox)  console that it's up and it claims the ports are up.
  • When I try to ping the WAN gateway ip though, I get "host is down".  Pinging a LAN host IP just gives no response.
  • When I change the VM guest config to have both WAN and LAN on the LAN bridge (vmbr0) I can actually reach the guest via the WAN port public ip, but pfsense then is not able to "talk" to the LAN.  The WAN port seems to be working though??
Anyone have any idea what changed from Debian 7 to 8 that may be causing this?

11
I was stuck with this issue, no replies, so I went through all the settings again.  Lo and behold!  There was no upstream gateway set on the WAN port (although I'm sure it was there at some stage before).



After setting it, all is well.

12
Since finding out some address route to the internet and others not, I checked which actually do route.  Turns out that only those with 1:1 NAT entries in pfSense can access the internet.

In Firewall: NAT: Outbound I have selected "Automatic outbound NAT rule generation (IPsec passthrough included) ".   It seems that this is not sufficient.

What should I do to make this work as expected?  Should I remove the 1:1 NAT and only put in inbound NAT rules?

13
(I have renamed the question to more correctly describe the symptoms)

If have done a lot of digging and testing re this issue and the news is somewhat better than I at first reported:

The routing works from some of the virtual machines, but not from others. 

To illustrate the point:

machine A: www

www:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ca:04:b6:f7:84:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.121.38/24 brd 192.168.121.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c804:b6ff:fef7:84c4/64 scope link
       valid_lft forever preferred_lft forever

@www:~$ ip route show
default via 192.168.121.1 dev eth0
192.168.121.0/24 dev eth0  proto kernel  scope link  src 192.168.121.38

machine B: redmine

redmine:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 3a:50:f6:52:b9:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.121.50/24 brd 192.168.121.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::3850:f6ff:fe52:b924/64 scope link
       valid_lft forever preferred_lft forever

redmine:~$ ip route show
default via 192.168.121.1 dev eth0
192.168.121.0/24 dev eth0  proto kernel  scope link  src 192.168.121.50

Both machines are configured with the same virtual hardware, yet machine A can access the internet (anything beyond the pfSense WAN port) while machine B can only access up to the WAN port, but not beyond that.

I have shut down machine A and then change machine B's ip address to 12.168.121.38 and when I restart it, it can access the internet perfectly.

So this all points to some obscure setting in pfSense that allows 192.168.121.38 out, but 192.168.121.50 not.

Were could that be?




14
/etc/defaults/rc.conf is NOT the place to mess with.

Not, I won't mess with anything, especially in freeBSD!  I was just looking around to see what I can discover to give me an indication of what may be causing the problem.  I'm pretty sure I didn't change anything since I upgraded, since everything "just worked" once it was set up.

So what do I do next?

15
I also see this:

Code: [Select]
cat /etc/defaults/rc.conf | grep gateway
defaultrouter="NO" # Set to default gateway (or NO).
gateway_enable="NO" # Set to YES if this host will be a gateway.
ipxgateway_enable="NO" # Set to YES to enable IPX routing.
forward_sourceroute="NO" # do source routing (only if gateway_enable is set to "YES")
ipv6_defaultrouter="NO" # Set to IPv6 default gateway (or NO).
ipv6_gateway_enable="NO" # Set to YES if this host will be a gateway.
# ipv6_gateway_enable="NO".

Is that the way it's supposed to be with pfSense?  It's seems like freeBSD's routing is turned off, or what?

Pages: [1] 2