I know that SpamAssassin can assign scores to a mail if specific words appear in a mail.

Like for instance mail contains the word bitcoin then add 1.0 to the total score.

But what about making a rule so a set of words tags mail as spam if and only if the whole set is matched in mail?

Like if you have the words internet and banking and interest then if one one of the words appear in mail it is not assigned a spam value, but a mail containing all the words will get a spam score, like for instance a mail with the message:

Get huge interest through internet banking.

The reason why I want SpamAssassin to match whole sets instead of individual words is because I get phishing mails that appear to look like legitimate mail, but they do share a common theme, like for instance failed renewal of "Brobizz" (danish version of E-ZPass).

And since the phishing mails looks exactly like the legitimate mail, it would be a bad idea to block all mail containing the words and no other criteria.

However: A combination of the words and a seperate rule saying sender mail servers ip address cannot be resolved would be good enough reason to flag mail as spam.

So is it possible to only assign score on a set of words?

I am building a container for Kubernetes that runs a SAMBA Active Directory Domain Controller.

I am doing the job through Ansible and the container is being deployed in a Kubernetes cluster (K3S).

Docker is using the following files as part of its build:

etc/krb5.conf
etc/bind/rndc.key
etc/bind/named.conf.local
etc/bind/db.0
etc/bind/db.255
etc/bind/db.empty
etc/bind/named.conf.options
etc/bind/db.local
etc/bind/named.conf
etc/bind/db.127
etc/bind/named.conf.default-zones
etc/supervisor/conf.d/supervisord.conf
etc/freeradius/3.0/mods-available/eap
etc/freeradius/3.0/mods-available/realm
etc/freeradius/3.0/mods-available/ntlm_auth
etc/freeradius/3.0/mods-available/mschap
etc/freeradius/3.0/clients.conf
etc/freeradius/3.0/proxy.conf
etc/freeradius/3.0/sites-available/default
etc/freeradius/3.0/sites-available/inner-tunnel
boot/init.sh
boot/kdb5_util_create.expect
Dockerfile

The idea is that for all files the path is the same inside the container, but / as a prefix.

However I came across something strange when inspecting the running container that was compiled as a result.

The content of /etc/samba, /etc/bind and /etc/freeradius is definitely not supposed to be the same!

The content of my Dockerfile is as follows:

FROM ubuntu:noble

ENV DEBIAN_FRONTEND noninteractive

# Avoid ERROR: invoke-rc.d: policy-rc.d denied execution of start.
RUN echo "#!/bin/sh\nexit 0" > /usr/sbin/policy-rc.d

VOLUME ["/var/lib/samba", "/etc/samba", "/etc/bind", "/etc/freeradius", "/SambaVolume"]

# Setup ssh and install supervisord
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y openssh-server supervisor ntp mc
RUN mkdir -p /var/run/sshd
RUN mkdir -p /var/log/supervisor
RUN sed -ri 's/PermitRootLogin without-password/PermitRootLogin Yes/g' /etc/ssh/sshd_config

# Add SAMBA VolumeShare location
RUN mkdir -p /SambaVolume

# Install bind9 dns server
RUN apt-get install -y bind9 dnsutils
# Copy tweaked DNS setttings (instead of ADD, due to we want to overwrite any existing files)
COPY etc/bind/* /etc/bind/

# Install samba and dependencies to make it an Active Directory Domain Controller
RUN apt-get install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5

# Install Freeradius so validate VPN users against samba
RUN apt-get install -y freeradius

# Copy Freeradius customised files
COPY etc/freeradius/ /etc/freeradius/

# Copy customized kerberos configuration file
COPY etc/krb5.conf /etc/

# Install utilities needed for setup
RUN apt-get install -y expect pwgen
ADD boot/kdb5_util_create.expect /root/kdb5_util_create.expect

# Install rsyslog to get better logging of ie. bind9
RUN apt-get install -y rsyslog

# Create run directory for bind9
RUN mkdir -p /var/run/named
RUN chown -R bind:bind /var/run/named

# Add supervisord and init
ADD etc/supervisor/conf.d/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ADD boot/init.sh /root/init.sh
RUN chmod 755 /root/init.sh
EXPOSE 53/tcp 53/udp 80/tcp 80/udp 88/tcp 88/udp 135/tcp 135/udp 137/tcp 137/udp 
EXPOSE 138/tcp 138/udp 389/tcp 389/udp 443/tcp 443/udp 445/tcp 445/udp 464/tcp 464/udp 
EXPOSE 636/tcp 636/udp 3268/tcp 3268/udp 3269/tcp 3269/udp 9389/tcp 9389/udp
EXPOSE 123/udp 22/tcp 22/udp
ENTRYPOINT ["/root/init.sh"]
CMD ["app:start"]

And the compiled container is being stored in a local register using the following commands:

  docker build -t samba:latest samba/
  docker tag samba:latest registry.example.com:5000/samba:latest
  docker push registry.example.com:5000/samba:latest  

It is being deployed through Ansible with the following task:

- name: Create SAMBA Deployment
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: samba
        namespace: samba-system
        labels:
          app: samba
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: samba
        template:
          metadata:
            labels:
              app: samba
          spec:
            volumes:
              - name: samba-config
                persistentVolumeClaim:
                  claimName: samba-config-vol

            containers:
              - name: samba
                image: registry.example.com:5000/samba:latest
                ports:
                  - containerPort: 123
                    protocol: UDP

#           ### SKIPPING ###

                 - containerPort: 9389
                    protocol: UDP
                  - containerPort: 9389
                    protocol: TCP

                volumeMounts:
                  - name: samba-config
                    mountPath: /etc/samba
                  - name: samba-config
                    mountPath: /etc/bind
                  - name: samba-config
                    mountPath: /etc/freeradius
                  - name: samba-config
                    mountPath: /var/lib/samba

                envFrom:
                  - configMapRef:
                      name: samba-environment-map

                securityContext:
                  priviledged: true
                  allowPrivilegeEscalation: true
                  readOnlyRootFilesystem: false

                  capabilities:
                    add:
                      - ALL

I am wondering why the content of the folders /etc/bind, /etc/samba and /etc/freeradius is the same.

I thought I read somewhere that you could use the same persistentVolumeClaim for all folders?

I am installing Home Assistant in my K3S Kubernetes cluster through Ansible and I want to use a Let's Encrypt certificate for my ingress that has been generated by Cert-Manager running on my cluster.

I am using the following playbook when installing Home Assistant:

---
- name: Create HomeAssistant namespace
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: home-system

- name: Generate certificate for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: homeassistant-tls
        namespace: home-system
      spec:
        secretName: homeassistant-tls-secret
        commonName: "homeassistant.example.com" 
        dnsNames:
        - "homeassistant.example.com"
        issuerRef:
          name: letsencrypt-staging
          kind: ClusterIssuer

- name: Get TLS certificate secret
  kubernetes.core.k8s_info:
    api_version: v1
    name: homeassistant-tls-secret
    kind: Secret
    namespace: home-system
  register: tls_secret
  
- name: Create ConfigMap for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: home-config
        namespace: home-system

      data:
        fullchain.pem: "{{ tls_secret.resources[0].data['tls.crt'] | b64decode }}"

        privkey.pem: "{{ tls_secret.resources[0].data['tls.key'] | b64decode }}"

        groups.yaml: |-

        scripts.yaml: |-

        scenes.yaml: |-

        known_devices.yaml: |- 
    
        automations.yaml: |-

        configuration.yaml: |-

          # Loads Default configuration - DO NOT REMOVE
          default_config:

          # Load frontend themes from the themes folder
          frontend:
            themes: !include_dir_merge_named themes
          
          # Text-to-speech
          tts:
            - platform: google_translate
          
          group: !include groups.yaml
          automation: !include automations.yaml
          script: !include scripts.yaml
          scene: !include scenes.yaml

          http:
            use_x_forwarded_for: true

            trusted_proxies:
            - 127.0.0.1
            - 10.42.0.0/16
            - 10.43.0.0/16
            - 192.168.0.0/24

            ssl_certificate: /ssl/fullchain.pem
            ssl_key: /ssl/privkey.pem

- name: Define storage space for HomeAssistant
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: homeassist-pvc
        namespace: home-system
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: small-longhorn # Store data on only 2 nodes instead of 3
        resources:
          requests:
            storage: 5Gi

- name: Add HomeAssistant StatefulSet
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: homeassistant
        namespace: home-system
        labels:
          app: homeassistant
      spec:
        serviceName: home-svc
        replicas: 1
        selector:
          matchLabels:
            app: homeassistant
        template:
          metadata:
            labels:
              app: homeassistant
          spec:
            volumes:
            - name: home-config-vol
              persistentVolumeClaim:
                claimName: homeassist-pvc

            - name: home-config-file
              configMap:
                name: home-config

            containers:
            - name: homeassistant
              image: lscr.io/linuxserver/homeassistant:latest
              ports:
                - containerPort: 8123
              volumeMounts:
              - name: home-config-vol
                mountPath: /config

              - name: home-config-file
                mountPath: /config/configuration.yaml
                subPath: configuration.yaml
                
              - name: home-config-file
                mountPath: /config/automations.yaml
                subPath: automations.yaml

              - name: home-config-file
                mountPath: /config/scripts.yaml
                subPath: scripts.yaml

              - name: home-config-file
                mountPath: /config/scenes.yaml
                subPath: scenes.yaml

              - name: home-config-file
                mountPath: /config/groups.yaml
                subPath: groups.yaml

              - name: home-config-file
                mountPath: /ssl/fullchain.pem
                subPath: fullchain.pem

              - name: home-config-file
                mountPath: /ssl/privkey.pem
                subPath: privkey.pem

              env:
                - name: PUID
                  value: "1000"
                - name: PGID
                  value: "1000"
                - name: TZ
                  value: "Etc/UTC"

            securityContext:
              capabilities:
                add:
                - NET_ADMIN
                - NET_RAW
                - SYS_ADMIN

              priviledged: true

- name: Define HomeAssistant service ports
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: home-svc
        namespace: home-system
        annotations: 
          metallb.universe.tf/address-pool: default-pool
      spec:
        type: LoadBalancer
        externalTrafficPolicy: Local
        selector:
          app: homeassistant
        ports:
          - name: "8123"
            port: 8123
            targetPort: 8123

- name: Add HomeAssistant ingress
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: homeassistant
        namespace: home-system

        annotations:
          kubernetes.io/ingress.class: nginx
          cert-manager.io/cluster-issuer: letsencrypt-staging
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
          nginx.ingress.kubernetes.io/ssl-redirect: "true"
          nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

      spec:
        ingressClassName: nginx
        tls:
        - hosts:
          - homeassistant.example.com
          secretName: homeassistant-tls

        rules:
        - host: 'homeassistant.example.com'
          http:
            paths:
            -  path: /
               pathType: Prefix
               backend:
                service:
                  name: home-svc
                  port:
                    number: 8123

I have replaced the actual FQDN with a name belonging to example.com. :-)

A few key points:

Home Assistant supports TLS encryption.

My first job is therefore to create a Let's Encrypt certificate, which I am naming homeassistant-tls. It has the associated secret homeassistant-tls-secret.

Next up is to extract certificate and key from the secret homeassistant-tls-secret and use it to create the files fullchain.pem and privkey.pem in the ConfigMap home-config.

The files contains the base64 decoded certificate and key.

The certificate and key files are then stored in the /ssl folder inside the container, which leads back to the last important file defined in the ConfigMap: configuration.yaml.

In order to enable TLS encryption we need to add the following lines to the http section of configuration.yaml:

  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

I tried calling the files tls.crt and tls.key, but apparently Home Assistant did not like it. :-)

All I know for sure is the files has to be PEM encoded.

After running the playbook I get the following output:

root@central:~# kubectl get svc -n home-system
NAME       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
home-svc   LoadBalancer   10.43.23.186   192.168.0.203   8123:30630/TCP   81m

root@central:~# kubectl get ingress -n home-system
NAME            CLASS   HOSTS                       ADDRESS         PORTS     AGE
homeassistant   nginx   homeassistant.example.com   192.168.0.200   80, 443   85m

The website is working when I enter the address: https://192.168.0.203:8123/ or https://homeassistant.example.com in the browser.

However when I inspect the associated certificates I get the following:

• https://192.168.0.203:803 (LoadBalancer) points at the Let's Encrypt certificate, which as far as I can tell is because I defined the certificates in the /ssl folder.
• https://homeassistant.example.com (Ingress) points at a generic Kubernetes cluster certificate.

So how do I also make Ingress use the correct certificate? :-)

Changing the secretName to homeassist-tls-secret does not work for certain. :-)

I running K3S Kubernetes on a cluster server consisting of a mixture of Raspberry 4 and Raspberry 5 nodes.

I want to install Unifi Network Application on the cluster server and have come pretty far in configuring along with MetalLB, Longhorn and Cert-Manager by using Ansible.

I am using linuxserver.io's Docker image for my cluster server and it requires me to install a seperate pod containing MongoDB.

Searching online for how to install MongoDB gave me the following Ansible file:

- name: Generate MongoDB secrets
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Secret
      metadata:
        name: mongodb-secret
        namespace: default
      type: Opaque
      data:
        password: VmVyeVNlY3JldFBhc3NvcmQ= # "VerySecretPassword" encoded in Base64

- name: Create Unifi DB init script
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: mongodb-init-script
        namespace: default
      data:
        init-script.js: |-
          db.getSiblingDB("unifi-db").createUser({user: "unifi", pwd: "unifi", roles: [{role: "dbOwner", db: "unifi-db"}]});
          db.getSiblingDB("unifi-db_stat").createUser({user: "unifi", pwd: "unifi", roles: [{role: "dbOwner", db: "unifi-db_stat"}]});

- name: Create MongoDB service
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: mongodb-svc
        namespace: default
        labels: 
          app: mongodb
      spec:
        type: ClusterIP
        ports:
        - protocol: TCP
          port: 27017
          targetPort: 27017
        selector:
          app: mongodb

- name: Create MongoDB statefull set
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: mongodb
        namespace: default
        labels:
          app: mongodb
      spec:
        serviceName: mongodb-svc
        replicas: 1
        selector:
          matchLabels:
            app: mongodb
        template:
          metadata:
            labels:
              app: mongodb
          spec:
            containers:
            - name: mongodb
              image: mongo:4.4.18 # Do NOT set it to 'latest'. I'll explain below.
              ports:
              - containerPort: 27017
              env:
              - name: MONGO_INITDB_ROOT_USERNAME
                value: admin

              - name: MONGO_INITDB_ROOT_PASSWORD
                valueFrom:
                  secretKeyRef:
                    name: mongodb-secret
                    key: password

              volumeMounts:
                - name: mongodb-data
                  mountPath: /data/db

        volumeClaimTemplates:
        - metadata:
            name: mongodb-data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 1Gi

- name: Initialize MongoDB
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: batch/v1
      kind: Job
      metadata:
        name: mongodb-init-job
        namespace: default
      spec:
        template:
          metadata:
            name: mongodb-init-pod
          spec:
            restartPolicy: OnFailure
            containers:
            - name: mongodb-init-container
              image: mongo:4.4.18 # Again: Do NOT set it to 'latest'.
              command: [ "mongo", "--host", "mongodb-0.mongodb-svc.default.svc.cluster.local", "--authenticationDatabase", "admin", "--username", "admin", "--password", "$(MONGO_INITDB_ROOT_PASSWORD)", "/mongo-init-script/init-script.js" ]
              
              env:
              - name: MONGO_INITDB_ROOT_PASSWORD
                valueFrom:
                  secretKeyRef:
                    name: mongodb-secret
                    key: password
              volumeMounts:
              - name: mongo-init-script
                mountPath: /mongo-init-script
            volumes:
            - name: mongo-init-script
              configMap:
                name: mongodb-init-script

The section works fine.

The output from kubectl logs mongodb-init-job-f5f54 is as follows:

MongoDB shell version v4.4.18
connecting to: mongodb://mongodb-0.mongodb-svc.default.svc.cluster.local:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("39ad2f51-07a9-4e67-8c5b-68f6fff92872") }
MongoDB server version: 4.4.18
Successfully added user: {
        "user" : "unifi",
        "roles" : [
                {
                        "role" : "dbOwner",
                        "db" : "unifi-db"
                }
        ]
}
Successfully added user: {
        "user" : "unifi",
        "roles" : [
                {
                        "role" : "dbOwner",
                        "db" : "unifi-db_stat"
                }
        ]
}

Which means I could login as admin and create a MongoDB user called unifi with password unifi that has access to the database unifi-db.

I also know that it is accessible via DNS by setting the database host to mongodb-0.mongodb-svc.default.svc.cluster.local using port 27017.

The reason why I chose to install version 4.4.18 of MongoDB is because even though Unifi Network Application supports up to version 7.0, it is not the same case with MongoDB support for the Raspberry Pi boards.

MongoDB can only run up til version 4.4.18 on Raspberry Pi.

Next up is getting Unifi Network Application to run on my cluster server.

I am using the following tasks to do this:

---
- name: Define storage space for Unifi
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: unifi-cluster-pvc
        namespace: default
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: longhorn
        resources:
          requests:
            storage: 5Gi

- name: Add unifi deployment
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: unifi
        namespace: default
        labels:
          app: unifi
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: unifi
        template:
          metadata:
            labels:
              app: unifi
          spec:
            volumes:
            - name: unifi-config
              persistentVolumeClaim:
                claimName: unifi-cluster-pvc
            containers:
            - name: unifi
              image: lscr.io/linuxserver/unifi-network-application:latest
              ports:
                - containerPort: 3478
                  protocol: UDP
                - containerPort: 10001
                  protocol: UDP
                - containerPort: 5514
                  protocol: UDP
                - containerPort: 8080
                - containerPort: 8443
                - containerPort: 8843
                - containerPort: 8880
                - containerPort: 6789
              volumeMounts:
              - name: unifi-config
                mountPath: /config
              env:
                - name: PUID
                  value: "1000"
                - name: GUID
                  value: "1000"
                - name: MONGO_USER
                  value: "unifi"
                - name: MONGO_PASS
                  value: "unifi"
                - name: MONGO_HOST
                  value: "mongodb-0.mongodb-svc.default.svc.cluster.local"
                - name: MONGO_PORT
                  value: "27017"
                - name: MONGO_DBNAME
                  value: "unifi-db"
                - name: MONGO_TLS
                  value: "false"

- name: Define unifi service ports
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Service
      metadata:
        name: unifi
        namespace: default
      spec:
        type: LoadBalancer
        selector:
          app: unifi
        ports:
          - name: "8080"
            port: 8080
            targetPort: 8080
          - name: "8443"
            port: 8443
            targetPort: 8443
          - name: "8843"
            port: 8843
            targetPort: 8843
          - name: "8880"
            port: 8880
            targetPort: 8880
          - name: "6789"
            port: 6789
            targetPort: 6789
          - name: "3478"
            port: 3478
            protocol: UDP
            targetPort: 3478
          - name: "10001"
            port: 10001
            protocol: UDP
            targetPort: 10001
          - name: "5514"
            port: 5514
            protocol: UDP
            targetPort: 5514

- name: Add unifi ingress
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: unifi
        namespace: default
        annotations:
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
          cert-manager.io/cluster-issuer: letsencrypt-staging
          cert-manager.io/acme-challenge-type: dns01
      spec:
        ingressClassName: nginx
        tls:
        - hosts:
          - unifi.example.com
          secretName: unifi-tls
        rules:
        - host: 'unifi.example.com'
          http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: unifi
                  port:
                    number: 8443

Running the command kubectl get pods gives me the following output:

NAME                     READY   STATUS      RESTARTS   AGE
mongodb-0                1/1     Running     0          64m
unifi-5dcdbfb6d9-8wbbp   1/1     Running     0          64m
mongodb-init-job-f5f54   0/1     Completed   2          64m

And I can login to the unifi-db database with the command: kubectl exec mongodb-0 -it -- mongo -u unifi -p unifi unifi-db

The command: show collections

Gives me amongst others the following:

account
admin
alarm
crashlog
dashboard
device
...

So far so good.

However I cannot get the website for Unifi Network Application up and running.

The output from the command kubectl log unifi-5dcdbfb6d9-8wbbp gives amongst others this message:

Error creating bean with name 'statDbService' 
defined in com.ubnt.service.DatabaseSpringContext: 
Command failed with error 13 (Unauthorized): 'not 
authorized on unifi-db_stat to execute command { 
listCollections: 1, cursor: {}, nameOnly: true, $db: 
"unifi-db_stat", lsid: { id: UUID("99b4d07f-b3f3-49c9-9979-dbdd27445881") 
} }' on server mongodb-0.mongodb-svc.default.svc.cluster.local:27017. 
The full response is {"ok": 0.0, "errmsg": "not authorized on unifi-db_stat 
to execute command { listCollections: 1, cursor: {}, nameOnly: true, $db: 
\"unifi-db_stat\", lsid: { id: UUID(\"99b4d07f-b3f3-49c9-9979-dbdd27445881\") 
} }", "code": 13, "codeName": "Unauthorized"}

How do I resolve this issue?

Reading the docs for how role assignment works in MongoDB, I can read that setting the role of a user to dbOwner is basically an all-access pass, since it combines the roles of readWrite, dbAdmin and userAdmin into one role.

One of the permissions that you get is listCollections, which is referenced in the errorcode above.

So what is going on?

I am trying to install Unifi on a Kubernetes cluster server (K3S) using Ansible and ran into troubles when trying to define a persistent volume claim.

I am using Kubernetes.Core module and I have defined my task as:

- name: Define storage space for Unifi
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: unifi-cluster-pvc
        namespace: default
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: longhorn
      resources:
        requests:
          storage: 100Mi

However when I run my playbook then I get the following error:

TASK [unifi : Define storage space for Unifi] 
***********************************************************************
fatal: [central.example.com]: FAILED! => {"changed": false, "msg": 
"Failed to create object: b'{\"kind\":\"Status\",\"apiVersion\":\"v1\",
\"metadata\":{},\"status\":\"Failure\",\"message\":\"PersistentVolumeClaim 
\\\\\"unifi-cluster-pvc\\\\\" is invalid: spec.resources[storage]: Required 
value\",\"reason\":\"Invalid\",\"details\":{\"name\":\"unifi-cluster-pvc\",
\"kind\":\"PersistentVolumeClaim\",\"causes\":[{\"reason\":\"FieldValueRequired\",
\"message\":\"Required value\",\"field\":\"spec.resources[storage]\"}]},\"code\":422}\\n'", 
"reason": "Unprocessable Entity"}

Is there anyone who can explain what is going on?

Because if I create a yaml file called test.yml with the following content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: unifi-cluster-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 100Mi

and run the command: kubectl apply -f test.yml on my controller

Then I get the message back:

persistentvolumeclaim/unifi-cluster-pvc created

I am trying to learn how Kubernetes works, so I have made my own K3S cluster using the quickstart guide.

Then I installed Cert Manager using the guide for Helm.

I want to use Let's Encrypt certificates for my cluster and validate them using the dns01 webhook with my DNS provider Simply.com.

This can be done by using a webhook found here:

https://github.com/RunnerM/simply-dns-webhook

Currently I am testing if I can a certificate from Let's Encrypt by using their staging server.

I made the Yaml file letsencrypt-staging.yaml with the following content for ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: default
spec:
  acme:
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-key
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        webhook:
          groupName: com.github.runnerm.cert-manager-simply-webhook
          solverName: simply-dns-solver
          config:
            secretName: simply-credentials # notice the name
      selector:
        dnsZones:
        - 'cluster.example.com'
        - '*.cluster.example.com'

My configuration file is basically a verbatim copy-paste from the example found at RunnerM GitHub page.

In order to issue a certificate I created a Yaml file called certificate-test.yaml with the following content:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-certificate
spec:
  dnsNames:
  - test.cluster.example.com
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

  secretName: test-certificate-tls

I should then be able to get a certificate issued by using the following to commands:

kubectl apply -f letsencrypt-staging.yaml
kubectl apply -f certificate-test.yaml

However I am not getting a certificate issued.

When running kubectl describe challenge test-certificate-1-1965387138-1295925723 i get the following error message:

...
Status:
  Presented:   false
  Processing:  true
  Reason:      secrets "simply-credentials" is forbidden: User "system:serviceaccount:default:my-simply-dns-webhook" cannot get resource "secrets" in API group "" in the namespace "cert-manager"
  State:       pending
E
...

I get that the Simply DNS webhook my-simply-dns-webhook is running in the default namespace and the Simply DNS credentials is stored in the cert-manager namespace.

So how do I permit the Simply DNS webhook to access resources in the cert-manager namespace?

Additional information

Running the command kubectl get clusterrolebindings gives amongst other the following informations:

my-simply-dns-webhook:secret-access                    ClusterRole/my-simply-dns-webhook:secret-access                    76s
simply-dns-webhook:challenge-management                ClusterRole/simply-dns-webhook:challenge-management                76s
my-simply-dns-webhook:domain-solver                    ClusterRole/my-simply-dns-webhook:domain-solver                    76s
my-simply-dns-webhook:flow-control                     ClusterRole/my-simply-dns-webhook:flow-control                     76s
my-simply-dns-webhook:auth-delegator                   ClusterRole/system:auth-delegator                                  76s

Output from kubectl get clusterrole my-simply-dns-webhook:secret-access gives the following result:

Name:         my-simply-dns-webhook:secret-access
Labels:       app=simply-dns-webhook
              app.kubernetes.io/managed-by=Helm
              chart=simply-dns-webhook-1.5.4
              heritage=Helm
              release=my-simply-dns-webhook
Annotations:  meta.helm.sh/release-name: my-simply-dns-webhook
              meta.helm.sh/release-namespace: default
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  secrets.*  []                 []              [get]

And the command kubectl describe clusterrolebindings my-simply-dns-webhook:secret-access gives the output:

Name:         my-simply-dns-webhook:secret-access
Labels:       app=simply-dns-webhook
              app.kubernetes.io/managed-by=Helm
              chart=simply-dns-webhook-1.5.4
              heritage=Helm
              release=my-simply-dns-webhook
Annotations:  meta.helm.sh/release-name: my-simply-dns-webhook
              meta.helm.sh/release-namespace: default
Role:
  Kind:  ClusterRole
  Name:  my-simply-dns-webhook:secret-access
Subjects:
  Kind            Name                   Namespace
  ----            ----                   ---------
  ServiceAccount  my-simply-dns-webhook  cert-manager

So what am I missing?

I can see that Android native VPN client supports IKEv2/MSCHAPv2, so in theory it should be possible to connect to Strongswan VPN server from Android without installing additional software (like the Strongswan VPN client).

However: In practise it is not quite as easy to make it work.

My server is using FreeRadius as a backend and is working fine with:

• iPhone native VPN client
• Windows 10/11 native VPN client
• StrongVPN client for Android.

So I thought it should be easy to brute force support Android native client, since the above were not that hard.

Well turn out it was not quite as easy.

Reading the logs to find out what was needed, I found this line:

14[CFG] received proposals: 
IKE:AES_CBC_256/AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_384_192/HMAC_SHA2_256_128/HMAC_SHA1_96/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048_256/ECP_384/ECP_256/MODP_2048/MODP_1536,
IKE:AES_GCM_16_256/AES_GCM_16_128/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048_256/ECP_384/ECP_256/MODP_2048/MODP_1536

As far as I have gathered that is Android telling Strongswan which encryption ciphre it supports.

Using: StrongSwans documentation for cipher suites I found out that I should make entry with a proposal for ciphres that contains either:

A combination of aes256/aes128, sha512/sha384/sha256/sha1, prfsha512/prfsha384/prfsha256/prfsha1 and modp2048s256/ecp384/ecp256/modp2048/modp1536.

Or:

A combination of aes256gcm16/aes128gcm16, prfsha512/prfsha384/prfsha256/prfsha1 and modp2048s256/ecp384/ecp256/modp2048/modp1536.

This led me to this proposal for IKE transport: aes256-sha512-prfsha512-modp2048s256.

My configuration for Android profile is as follows:

conn-defaults {
    local_addrs = SERVER.IP.ADDRESS

    local {
      auth = pubkey
      certs = example.com-ecdsa.cer
      id = example.com
    }

    version = 2
    send_certreq = no
    send_cert = always
    unique = never
    fragmentation = yes
    encap = yes
    dpd_delay = 60s

    rekey_time = 0s
}

# Default login method
eap-defaults {
  remote {
   auth = eap-radius
   id = %any
   eap_id = %any
  }
}

eap-android : eap-default {
  remote {
    # Do NOT define eap_id, since Radius won't get triggered on login.
    auth = eap-radius
    id = *@example.com    
  }
}

connections
{
  conn-android : conn-defaults, eap-android {

    children {
      net {
        local_ts = 0.0.0.0/0
      }

      esp_proposals = aes256-sha512-prfsha512-modp2048s256
    }

    pools = IkeVPN-ipv4
    proposals = aes256-sha512-prfsha512-modp2048s256
  }

  conn-windows : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    proposals = aes256-sha256-prfsha256-modp1024
    pools = IkeVPN-ipv4
  }

  conn-ios : conn-defaults, eap-defaults {

    local {
      auth = pubkey
      certs = example.com-rsa.cer
      id = example.com
    }

    children {
      net {
        local_ts = 0.0.0.0/0
      }

      esp_proposals = aes256-sha256
    }

    pools = IkeVPN-ipv4
    proposals = aes256-sha256-prfsha256-modp2048
  }
}

pools
{
  IkeVPN-ipv4 {
    addrs = 192.168.201.0/24

    #My DNS server is hosted on another internal net.
    dns = 192.168.200.1
  }
}

A quick note on certificates on my VPN server. I got 2 Let's Encrypt certificates installed.

A 2048-bit RSA certificate (used by iPhone users, since they can't connect to a ECDSA certfificate?).

A 256-bit ECDSA certificate, which is used by all OS that supports ECDSA.

A little bit of trial and error led me to the configuration of the eap-android section, but from there I was a bit stumped.

First off: During configuration of Andoid VPN I quickly learned that I had to define ipsec identifier though I am a bit unsure what it is being used for during login.

I did notice that whatever I used as a value in ipsec identifier would be matched against the id attribute in the remote section. Therefore I just copied the content from username into ipsec identifier.

However trying to login to VPN server Android native client gave me the following output in log (slightly redacted):

14[CFG] looking for peer configs matching SERVER.IP.ADDRESS[%any]...CLIENT.IP.ADDRESS[[email protected]]
14[CFG] selected peer config 'conn-android'
14[CFG] sending RADIUS Access-Request to server '192.168.200.1'
14[CFG] received RADIUS Access-Challenge from server '192.168.200.1'
14[IKE] initiating EAP_TTLS method (id 0x01)
14[IKE] peer supports MOBIKE
14[IKE] authentication of 'example.com' (myself) with ECDSA_WITH_SHA256_DER successful
14[IKE] sending end entity cert "CN=EXAMPLE.COM"
14[IKE] sending issuer cert "C=US, O=Let's Encrypt, CN=R3"
14[ENC] generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/TTLS ]
14[NET] sending packet: from SERVER.IP.ADDRESS[4500] to CLIENT.IP.ADDRESS[6727] (3056 bytes)
07[NET] received packet: from SERVER.IP.ADDRESS[6727] to CLIENT.IP.ADDRESS[4500] (96 bytes)
07[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
07[ENC] generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]
07[NET] sending packet: from SERVER.IP.ADDRESS[4500] to CLIENT.IP.ADDRESS[6727] (96 bytes)

Digging further into FreeRadius by running it through freeradius -X I found that Freeradius received username and sends a challange back to VPN client, but it never receives a response to the challenge from VPN client.

Is there anyone that knows what is going on since username authentication hangs up in the middle of login?

This is a continuation of my previous question in sending static routes from Freeradius DHCP server implementation in combination with Strongswan VPN server.

When debugging Freeradius using tcpdump and Wireshark I found out that I can send classless static routes from Freeradius DHCP server by through adding DHCP-Classless-Static-Route and DHCP-Site-specific-25 (aka Microsoft static route) options to my DHCP-Discover and DHCP-Request sections of the dhcp server configuration file.

However: It appears that the static routes are not accepted by Microsoft VPN client if I set the default gateway to be 0.0.0.0 as suggested by Strongswan documentation.

At least I cannot find the advetised routes on my Windows client when using route print -4.

Also I cannot add the routes manually on Windows client when I am using 0.0.0.0 as standard gateway over VPN interface.

However:

Lets say I want to access the subnet 192.168.200.0/24 over VPN and my VPN server assign the address 192.168.201.2/24 to my Windows client. Then it is actually possible to create a static route on windows client side by declaring that the subnet 192.168.200.0/24 is accessible via 192.168.201.2 using the windows command:

route add 192.168.200.0 mask 255.255.255.0 192.168.201.2

I know it looks a bit weird, but I can ping any host on the 192.168.200.0 subnet, so as long as it works I am happy. :-)

But: I would be more happy if I could do the same thing by advertising the routes from my VPN server instead of doing it manually on all VPN clients. :-)

That means I have to do a bit of dynamic programming to the DHCP configuration in Freeradius. I my case it means I have to make a reference to a perl module in DHCP-Discover and DHCP-request that grabs the assigned client vpn ip address, convert it into octets and combine it with the static routes that is also given as octets.

An example:

The subnet 192.168.200.0/24 will be encoded as 0x18c0a8c8 as subnet mask is encoded first.

The client 192.168.201.2/24 will be encoded as 0xc0a8c902 as it is just converting each number in the ip address to hex.

The final encoding for the route will be: 0x18c0a8c8c0a8c902 as it is just a concatination of the two strings.

I then have to use update reply with the following code:

  update reply {
    &DHCP-Classless-Static-Route = 0x18c0a8c8c0a8c902
    &DHCP-Site-specific-25 = 0x18c0a8c8c0a8c902
  }

If there are any more routes then all the routes will be concatenated into one long string.

The tricky part:

Assume you have the default configuration of Freeradius DHCP server as found in freeradius/3.0/sites-available/dhcp file.

The general structure of the file for DHCP-Discover and DHCP-Request is as follows:

dhcp DHCP-Request {
  update reply {
    &DHCP-Message-Type = DHCP-Ack
  }

  update reply {
    # General DHCP options, such as default GW, DNS, IP-address lease time etc.
  }

  update control {
    &Pool-Name := "vpn_pool"
  }

  dhcp_sqlippool

  ok
}

Then as far as I have gathered I need to call my perl module after dhcp_sqlippool has been called and before returning ok, because dhcp_sqlippool is the module that assigns the ipaddress to the VPN client.

That means my version would be something like:

dhcp DHCP-Request {
  update reply {
    &DHCP-Message-Type = DHCP-Ack
  }

  update reply {
    # General DHCP options, such as default GW, DNS, IP-address lease time etc.
  }

  update control {
    &Pool-Name := "vpn_pool"
  }

  dhcp_sqlippool

  perl

  # If perl module returned no error
  if(ok) {
    update reply {
      # Perl-Route contains a hex encoded string with all routes.
      &DHCP-Classless-Static-Route = Perl-Route
      &DHCP-Site-specific-25 = Perl-Route      
    }
  }

  # Not sure if this one is needed?
  update reply {
    &DHCP-End-Of-Options = 255
  }

  ok
}

In order to make it work, I have to enable perl under the freeradius/3.0/mods-enabled folder and modify the filename in freeradius/3.0/mods-enabled/perl to point it to my perl module. Like for instance:

filename = ${modconfdir}/${.:instance}/dhcp/Options.pm

But how do I do reference the call to perl the right way?

I thought I had to enable the line func_post_auth = post_auth in freeradius/3.0/mods-enabled/perl and create a sub post_auth section in my perl module to handle calls from Freeradius, but as far as I can see in my log I get the following error in Freeradius:

(8) perl: perl_embed:: module = /etc/freeradius/3.0/mods-config/perl/dhcp/Options.pm , 
func = post_auth exit status= Undefined subroutine &main::post_auth called.
...
(8)     [perl] = fail
(8)   } # dhcp DHCP-Discover = fail

So what is it that I am not seeing?

I am trying to setup a Strongswan server that runs in split tunnel mode, which means I have to disable using the server as a default gateway on client side and also disable classfull routing in the VPN client.

I then have to send DHCP option 121 (classless static route) and DHCP option 249 (Microsoft variant of classless static route) when a client request an ip-address from Strongswan VPN server.

I need both option 121 and 249 in order to account for all combinations of operating systems that can connect (Windows, Linux, Android, MacOS, iPhones etc).

I did not have that much success in using ISC DHCP server with Strongswan, since it was not happy to listen on trafic over a WireGuard interface. It said it didn't support WireGuard or loopback interface and it basically ignored DHCP requests comming from the Strongswan VPN server on the other side of the wireguard link.

So I switched to Freeradius DHCP server, since Strongswan was already using Freeradius for user authentication when logging into the Strongswan VPN server.

After all: How hard could it be, since I was just going to add "a few config files to Freeradius"? :-)

Turns out it is a little tricky, but I managed to get Freeradius to listen to traffic on my Wireguard link using the following configuration:

listen {
        type = dhcp
        # The subnet 192.168.200.0/24 is my WireGuard subnet that act as a 
        # VPN site-to-site backbone.

        ipaddr = 192.168.200.4
        src_ipaddr = 192.168.200.4
        port = 67
        interface = wg0
        broadcast = no
}

In my strongswan.conf file I have the following:

charon {
  load_modular = yes
  plugins {
    include strongswan.d/charon/*.conf

    dhcp {
        force_server_address = yes
        identity_lease = yes
        interface = wg0
        load = yes
        server = 192.168.200.4
        use_server_port = yes
    }
  }
}

Anyhow: I have gotten Freeradius DHCP server to handout ip-addresses to VPN client when Strongswan sends DHCP-Discover or DHCP-Request to Freeradius DHCP server, but somehow I cannot get it to send the static routes?

I can see in the file dictionary that resides in /etc/freeradius/3.0 that the dictionary for dhcp specific options is being loaded from /usr/share/freeradius/dictionary.dhcp.

In that file I can find the two following informations:

# Classless Static Route Option
ATTRIBUTE       DHCP-Classless-Static-Route             121     octets

...

ATTRIBUTE       DHCP-Site-specific-25                   249     octets

According to StrongSwan Wiki I can set the next hop gateway for my static route to 0.0.0.0, so if I want to tell that the subnet 192.168.200.0/24 is accessible through the VPN link I have to encode the route as octets written as hex code using the order: {CIDR}{Network}{Gateway}.

So 192.168.200.0/24 via 0.0.0.0 becomes 0x18C0A8C800000000

So I thought that I should just modify the update reply in dhcp DHCP-Discover and dhcp DHCP-Request to the following:

update reply {
    &DHCP-Domain-Name-Server = 192.168.200.1
    &DHCP-Subnet-Mask = 255.255.255.0
    &DHCP-IP-Address-Lease-Time = 86400
    &DHCP-Classless-Static-Route = 0x18C0A8C800000000
    &DHCP-Site-specific-25 = 0x18C0A8C800000000
    &DHCP-DHCP-Server-Identifier = 192.168.200.4
}

However I cannot see that the route is being pushed to my routing table, when I try to login via Windows VPN client.

So what am I missing?

Update

Turns out the encoding for DHCP Option 249 is a tiny bit different than DHCP option 121.

At least according to Microsoft webpage for DHCP option 249.

However I am getting a little bit confused to how this translates to encoding in Freeradius.

As far as I can tell, I have already told that the header begins with DHCP option 249, due to how DHCP-Site-specific-25 is being defined in the dictionary.

But Microsoft webpage says that the first byte after that is the length of the all the routes in the DHCP measured in bytes, followed by the same encoding for the routes as defined in DHCP option 121.

So the encoded route 0x18C0A8C800000000 must be prepended with 08, so line with Microsoft Static Routes now reads:

&DHCP-Site-specific-25 = 0x0818C0A8C800000000

I have tested with that modification, but still no luck.

Second update

A little more fiddeling with the configuration file for DHCP and then monitoring via tcpdump on what is actually going on.

Whenever a client log on to Strongswan the request for an IP address is forwarded to DCHP server, so in essense Strongswan is acting as DHCP relay agent if I got that part right.

In tcpdump i can see the following exchange taking place:

Client sends DHCP Discover Server replies with DHCP Offer Client sends DHCP Request Server replies with DHCP ACK

My first takeaway from monitoring tcpdump is that I dont have to calculate bytelength on the encoded static route, because that garbles up the output from tcpdump.

In other words encoding for DHCP option 121 and DHCP option 249 is the same.

Further reading suggest static routing is associated with DHCP Information, but I never saw that packet in tcpdump.

The output from tcpdump when running with my initial configuration of update reply above gives the following session:

tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes

10:58:17.185671 IP (tos 0x0, ttl 64, id 46089, offset 0, flags [none], proto UDP (17), length 300)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Request from 7a:a7:8f:1f:b7:88, length 272, xid 0x5c9716b5, Flags [none] (0x0000)
          Gateway-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 22: hardware-type 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64:2e:65:75
            Parameter-Request Option 55, length 2:
              Domain-Name-Server, Netbios-Name-Server
            END Option 255, length 0

10:58:17.195305 IP (tos 0x0, ttl 64, id 19475, offset 0, flags [none], proto UDP (17), length 328)
    192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Reply, length 300, xid 0x5c9716b5, Flags [none] (0x0000)
          Your-IP 192.168.201.13
          Gateway-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Domain-Name-Server Option 6, length 4: 192.168.200.1
            Lease-Time Option 51, length 4: 86400
            Server-ID Option 54, length 4: 192.168.200.4
            Classless-Static-Route Option 121, length 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, length 8: (192.168.200.0/24:0.0.0.0)
            END Option 255, length 0
            PAD Option 0, length 0, occurs 12

10:58:17.219444 IP (tos 0x0, ttl 64, id 46098, offset 0, flags [none], proto UDP (17), length 312)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Request from 7a:a7:8f:1f:b7:88, length 284, xid 0x5c9716b5, Flags [none] (0x0000)
          Gateway-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 22: hardware-type 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64:2e:65:75
            Requested-IP Option 50, length 4: 192.168.201.13
            Server-ID Option 54, length 4: 192.168.200.4
            Parameter-Request Option 55, length 2:
              Domain-Name-Server, Netbios-Name-Server
            END Option 255, length 0

10:58:17.228663 IP (tos 0x0, ttl 64, id 19477, offset 0, flags [none], proto UDP (17), length 328)
    192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9d02!] BOOTP/DHCP, Reply, length 300, xid 0x5c9716b5, Flags [none] (0x0000)
          Your-IP 192.168.201.8
          Gateway-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Domain-Name-Server Option 6, length 4: 192.168.200.1
            Lease-Time Option 51, length 4: 86400
            Server-ID Option 54, length 4: 192.168.200.4
            Classless-Static-Route Option 121, length 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, length 8: (192.168.200.0/24:0.0.0.0)
            END Option 255, length 0
            PAD Option 0, length 0, occurs 12

The fact that I can see Classless-Static-Route and Classless-Static-Route-Microsoft being announced and they indeed tells that the subnet 192.168.200.0/24 is available through the tunnel, gives me hint that I am on the right track.

However:

The route does still not appear in my routing table.

Perhaps it has something todo with the following line:

192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Reply, length 300, xid 0x5c9716b5, Flags [none] (0x0000)

Anyone knows what is what needs fixing?

I am trying to setup Strongswan for VPN split tunneling.

What I want is only the subnets 10.88.0.0/16 and 10.0.200.0/24 is accessible through the VPN tunnel. Everyting else is handled throught the default gateway for the network.

All clients are assigned an ip adress belonging to the 10.0.201.0/24 subnet.

In my configuration file I have among others the following:

# Default login method
eap-defaults {
  remote {
   auth = eap-radius
   id = %any
   eap_id = %any
  }
}

connections
{
  conn-unix : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 10.0.200.0/24, 10.88.0.0/16
      }

      esp_proposals = aes128gcm128-x25519
    }

    pools = IkeVPN-ipv4
    proposals = aes128-sha256-x25519
  }

  conn-windows : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 10.0.200.0/24, 10.88.0.0/16
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    proposals = aes256-sha256-prfsha256-modp1024
    pools = IkeVPN-ipv4
  }
}

pools
{
  IkeVPN-ipv4 {
    addrs = 10.0.201.0/24
    dns = 10.0.88.2
  }
}

When I login over VPN it is possible to ping hosts belonging to 10.88.0.0/16 and 10.0.200.0/24, so I know I can use the VPN tunnel.

However:

If I try to access any other ressource on the Internet while still being connected to the VPN, then I cannot even ping the ip adress belonging to that ressourse.

In my routing table on my Windows computer I can find the following entries:

I know that when you have two routes to a given subnet like 0.0.0.0/0 in the routing table, then whatever rule has the lowest metric wins and traffic is forwarded using that rule.

However I do not want the VPN server to install a default route via VPN, but rather only tell that the subnets 10.88.0.0/16 and 10.0.200.0/24 has to be routed via VPN.

What I want is that I see a routing table closer to this without having to edit the routing table by hand on every VPN client:

So how do I go about doing that?

I am building a Podman container that runs Samba Active Directory with Bind9 and Freeradius support using Ansible and have runned into a bit of a snag.

Samba runs fine with DLZ_BIND as backend in my container, but I need to integrate Freeradius into the container, so I can support logins via VPN.

I am trying to templating the following line in /etc/freeradius/3.0/mods-available/mschap:

ntlm_auth = "/usr/bin/ntlm_auth --allow-mschapv2 
  --request-nt-key 
  --username={mschap:User-Name} 
  --domain={{ ad_info.netbios_domain }} 
  --challenge=%{%{mschap:Challenge}:-00} 
  --nt-response=%{%{mschap:NT-Response}:-00}"

For the sake of the exercise you can assume that the value of {{ ad_info.netbios_domain }} is EXAMPLE.

It is the only place in the file where I use a Jinja variable.

However running ansible-playbook makes Ansible basically blow up in my face, when it tries to template the file.

I presume it is because the Jinja variable is inserted inside a qouted string? Because a BASH shell script containing the following line will not blow up in ansible:

SAMBA_ADMIN_PASSWORD="{{ ad_info.admin_password }}"

So what are the right way to use Jinja, when you have a quoted string?

Edit

I made a template containing only the line in question and got the follwing error from ansible:

failed: [myhost.example.com] (item=etc/freeradius/3.0/mods-available/mschap) => 
{
  "ansible_loop_var": "item", 
  "changed": false, "item": 
  "etc/freeradius/3.0/mods-available/mschap-jinja", 
  "msg": "AnsibleError: template error while templating string: tag name expected. 

  String: ntlm_auth = \"/usr/bin/ntlm_auth 
    --allow-mschapv2 
    --request-nt-key 
    --username={mschap:User-Name} 
    --domain={{ ad_info.netbios_domain }} 
    --challenge=%{%{mschap:Challenge}:-00} 
    --nt-response=%{%{mschap:NT-Response}:-00}\"
"}

I have a StrongSwan VPN that for some reason unknown to me cannot connect iOS users to my VPN server.

A few quick notes:

• My StrongSwan server is front for VPN clients who connects to my network. I used WireGuard for my backend site-to-site routing.

• All StrongSwan VPN users are validated against a FreeRadius server.

• StrongSwan clients are assigned an IP on the 192.168.201.0/24 subnet, while WireGuard backbone net is running on the 192.168.200.0/24 subnet.

• All clients are also handed a public IPv6 address belonging to a /48 subnet assigned to me.

I run StrongSwan on Ubuntu 20.04 and my configuration file is located in the /etc/swanctl/config/ folder and is included by default due to filename ends on .conf.

The content are as follows:

# Default VPN server settings for all connections
conn-defaults {
    local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

    local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
    }

    version = 2
    send_certreq = no
    send_cert = always
    unique = never
    fragmentation = yes
    encap = yes
    dpd_delay = 60s

    rekey_time = 0s
}

# Default login method
eap-defaults {
  remote {
   auth = eap-radius
   id = %any
   eap_id = %any
  }
}

connections
{
  # Generic Android configuration that is extended further down.
  #
  # Works with StrongSwan VPN client for Android
  conn-unix : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      net-unix : child-defaults {
      }

      esp_proposals = aes128gcm128-x25519
    }

    proposals = aes128-sha256-x25519
  }

  # All Windows klients matches this rule as username validation 
  # is done by 'eap_start = yes' in strongswan.conf. 
  #
  # Works with Windows 10 built-in VPN client.
  conn-windows : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    proposals = aes256-sha256-prfsha256-modp1024
    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6

  }

  # A very similar configuration to Windows clients 
  # configuration, except iOS uses 2048 bit keys, 
  # while Windows uses 1024 bit keys.
  #
  # Does NOT work in its current state.
  conn-ios : conn-defaults, eap-defaults {
    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6

    }

    proposals = aes256-sha256-prfsha256-modp2048
  }

  # Android users is matched against this connection as they are 
  # running the app StrongSwan VPN client. Username is passed in the
  # 'id' field to StrongSwan VPN server.
  conn-unix-site : connections.conn-unix {
    remote {
      id = *@site.example.com
    }
    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
  }
}

pools
{
   IkeVPN-site-ipv4 {
      addrs = 192.168.201.0/24
      dns = 192.168.200.1
   }

   IkeVPN-site-ipv6 {
      addrs = 2001:db8:cafe::/97
      dns = 2001:db8::1
   }
}

My configuration is created using the structure given from the following webpage:

https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf#Referencing-other-Sections

The reason why I use it is due to avoiding to repeat same configuration settings across all my connection profiles.

If you are not familiar to this setup the following configuration for conn-ios this should be considered equivalent:

conn-ios {
   # Obtained from conn-default
   local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

   local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
   }

   version = 2
   send_certreq = no
   send_cert = always
   unique = never
   fragmentation = yes
   encap = yes
   dpd_delay = 60s

   rekey_time = 0s

   # Obtained from eap-defaults
   remote {
      auth = eap-radius
      id = %any
      eap_id = %any
   }

   # Obtained from original conn-ios profile above.
   children {
      net {
         local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
   }

   proposals = aes256-sha256-prfsha256-modp2048
}

The server certificate listed in the conn-default section is a ECDSA certificate obtained from Let's Encrypt using Acme.sh.

The encryption values for proposalsand esp_proposals in the iOS configuration is taken from the hint in: https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients.

When testing all combinations of Android or Windows users connects without any issues, but when somebody tries to login using iPhone the connection then stalls.

Output from log when an iPhone tries to connect is as follows:

10[IKE] CLIENT_IPV4 is initiating an IKE_SA
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
10[IKE] no matching proposal found, trying alternative config
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
10[IKE] no matching proposal found, trying alternative config
10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[IKE] remote host is behind NAT
10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
10[NET] sending packet: from PUBLIC_IPV4[500] to CLIENT_IPV4[6452] (456 bytes)
06[NET] received packet: from CLIENT_IPV4[13549] to PUBLIC_IPV4[4500] (512 bytes)
06[ENC] unknown attribute type INTERNAL_DNS_DOMAIN
06[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
06[CFG] looking for peer configs matching PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[PRIVATE_CLASS_A_ADDRESS]
06[CFG] selected peer config 'conn-ios'
06[IKE] initiating EAP_IDENTITY method (id 0x00)
06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
06[IKE] peer supports MOBIKE
06[IKE] authentication of 'vpn.example.com' (myself) with ECDSA-256 signature successful
06[IKE] sending end entity cert "CN=vpn.example.com"
06[IKE] sending issuer cert "C=US, O=Let's Encrypt, CN=R3"
06[ENC] generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
06[ENC] splitting IKE message (2816 bytes) into 3 fragments
06[ENC] generating IKE_AUTH response 1 [ EF(1/3) ]
06[ENC] generating IKE_AUTH response 1 [ EF(2/3) ]
06[ENC] generating IKE_AUTH response 1 [ EF(3/3) ]
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (1236 bytes)
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (1236 bytes)
06[NET] sending packet: from PUBLIC_IPV4[4500] to CLIENT_IPV4[13549] (500 bytes)
11[JOB] deleting half open IKE_SA with CLIENT_IPV4 after timeout

iPhone users are connecting using the built-in VPN client using the following settings:

• Type IKEv2

• Description: VPN server

• Server: vpn.example.com

• Remote id: vpn.example.com

• Local id: BLANK

• Username and password authentication.

• Username: [email protected]

• Password: ItIsASecret

Does anyone know why the connection stalls for iOS users when it has loaded the conn-ios profile?

UPDATE And we have liftoff! :-)

As per advice from @ecdsa I have switched the certificate to a 2048-bit RSA certificate.

My Radius server gets called. User authentication succeeds and client gets assign ip-adresse. I am happy. :-)

My configuration for conn-ios is now:

  conn-ios : conn-defaults, eap-defaults {

    # Overriding defaults from 'conn-default'
    local {
      auth = pubkey
      certs = vpn-rsa.cer
      id = vpn.example.com
    }

    children {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256
    }

    pools = IkeVPN-site-ipv4, IkeVPN-site-ipv6
    proposals = aes256-sha256-prfsha256-modp2048
  }

Everything else is as-is from my initial configuration.

My strongswan VPN server is authenticating VPN clients against a local Freeradius server.

All user logings is proxied to remote radius server, that validates users against a Samba Active Directory server.

However I have runned into a bit of a problem.

The following section works for Android users using Strongswan VPN client:

connections
{
  rw-eap {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }
    remote-android {
      auth = eap-radius
      id = *@example.com
    }
  }
}

Monitoring output from Freeradius reveals stuff like:

(5) Received Access-Request Id 135 from 192.168.200.1:47851 to 192.168.200.1:1812 length 193
(5)   User-Name = "[email protected]"
(5)   NAS-Port-Type = Virtual
(5)   Service-Type = Framed-User
(5)   NAS-Port = 4
(5)   NAS-Port-Id = "rw-eap"
(5)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(5)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(5)   Calling-Station-Id = "CLIENT_IPV4[3988]"

And log from Strongswan gives:

06[IKE] IKE_SA rw-eap[6] established between SERVER_PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[[email protected]]

However when trying to connect to the server from a Windows client it is pretty much dead in the water unless I use the following configuration in Strongswan:

connections
{
  rw-windows {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }

    remote-windows {
      auth = eap-radius

      # Don't use *@example.com here - as windows does not pass username as id, 
      # so this config will not match in that case.
      id = %any
    }
  }
}

Using this configuration I can at least get Strongswan to initiate Radius authentication, but I dont get much further than this.

Output from Freeradius gives me stuff like:

(21) Received Access-Request Id 151 from 192.168.200.1:47851 to 192.168.200.1:1812 length 306
(21)   User-Name = "\300\250\000d"
(21)   NAS-Port-Type = Virtual
(21)   Service-Type = Framed-User
(21)   NAS-Port = 7
(21)   NAS-Port-Id = "rw-windows"
(21)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(21)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(21)   Calling-Station-Id = "CLIENT_PUBLIC_IPV4[3989]"

And this result in the following entry in Strongswan log:

06[CFG] looking for peer configs matching SERVER_PUBLIC_IPV4[%any]...CLIENT_PUBLIC_IPV4[CLIENT_PRIVATE_IPV4]

This leads my a few questions like:

• First: Why does Windows VPN client not pass username as its ID like Strongswan do?

• Second: Why is the username passed from Strongswan to Freeradius "\300\250\000d"?

A little more debugging on Windows client:

The example above is generated when using EAP-TTLS on client side with MS-CHAP v2.

When using MS-CHAP instead Freeradius do get invoked with correct username, but when the request is proxied then the username / password authentication fails.

I guess the MS-CHAP login needs to be encapsulated or something since the encoding of the authentication request is not the same as when Android users connects?

I am trying to setup a proxy Freeradius server that forwards all requests to another Freeradius server.

For reference see the following picture:

The reason for this setup is I want users to be to onnect to the local LAN via VPN, but the local site is not accessible due to NAT implementet at the ISP.

I am however able to make a site2site VPN connection from local LAN to the VPN server, so I want users to be able to make a VPN connection to the local network via the public VPN server, provided they are a valid user on the local net.

I have a Freeradius server running on local LAN that validates users against a database - and that part is working fine.

Configuration VPN server side

As far as I understand the only thing I need to modify on the server is the file proxy.conf.

Assuming usernames logging onto the VPN is on the form [email protected] then I would only need to add the following entry to proxy.conf:

realm example.com {
    type = radius
    secret = VeryS3cretPassw0rd

    authhost = local-radius.example.com:1812
    accthost = local-radius.example.com:1813

    nostrip
}

The nostrip entry is making sure that the proxied request does not remove the @-postfix from username.

I would also need to add the following to /etc/hosts:

   # VPN Address of local-radius.example.com
 
   192.168.100.2   local-radius.example.com

Configuration local radius server side

On the local radius server I need to update client.conf so any queries to the local radius server and originating from the VPN ip adress is permittet. Like for instance this entry:

client vpn-net {

        # Allow requests originating from VPN subnet.

        ipaddr          = 192.168.100.0/24
        secret          = VeryS3cretPassw0rd
}

Running the following command on VPN server works as expected:

radtest -t mschap [email protected] SecretPassword local-radius.example.com:1812 0 VeryS3cretPassw0rd

I get the following response back:

Sent Access-Request Id 108 from 0.0.0.0:47466 to 192.168.100.2:1812 length 148
        User-Name = "[email protected]"
        MS-CHAP-Password = "SecretPassword "
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 0
        Message-Authenticator = 0x00
        Cleartext-Password = "SecretPassword"
        MS-CHAP-Challenge = ....
        MS-CHAP-Response = ...
Received Access-Accept Id 108 from 192.168.100.2:1812 to 192.168.100.1:47466 length 84
        MS-CHAP-MPPE-Keys = ...
        MS-MPPE-Encryption-Policy = Encryption-Required
        MS-MPPE-Encryption-Types = 4

However running the following command on the VPN server fails:

radtest -t mschap [email protected] SecretPassword localhost:18120 0 testing123

The output from the command is:

Sent Access-Request Id 104 from 0.0.0.0:39558 to 127.0.0.1:18120 length 148
        User-Name = "[email protected]"
        MS-CHAP-Password = "SecretPassword"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 0
        Message-Authenticator = 0x00
        Cleartext-Password = "SecretPassword"
        MS-CHAP-Challenge = ...
        MS-CHAP-Response = ...
Received Access-Reject Id 104 from 127.0.0.1:18120 to 127.0.0.1:39558 length 20
(0) -: Expected Access-Accept got Access-Reject

Running the command freeradius -X on VPN server gives among others this output:

(0) mschap: Found MS-CHAP attributes.  Setting 'Auth-Type  = mschap'
(0)     [mschap] = ok
(0) suffix: Checking for suffix after "@"
(0) suffix: Looking up realm "example.com" for User-Name = "[email protected]"
(0) suffix: Found realm "example.com"
(0) suffix: Adding Realm = "example.com"
(0) suffix: Proxying request from user [email protected] to realm example.com
(0) suffix: Preparing to proxy authentication request to realm "example.com"
(0)     [suffix] = updated
(0) ntdomain: Request already has destination realm set.  Ignoring
(0)     [ntdomain] = noop
(0) eap: No EAP-Message, not doing EAP
(0)     [eap] = noop
(0)     [files] = noop
(0)     [expiration] = noop
(0)     [logintime] = noop
(0)     [pap] = noop
(0)   } # authorize = updated
(0) There was no response configured: rejecting request

Monitoring freeradius on local net indicates that the server was never called, from the vpn server, so what am I missing?

I am trying to make a caching / forwarding only DNS server using Bind9 with DNSSEC validation being enabled by default.

Assume you have the following informations from my config file:

acl "home-net"
{
    127.0.0.1;
    ::1;
    192.168.1.0/24;
    2000:db8:cafe:100::/64;
};

options
{
    forwarders
    {
       # Use Google DNS either by IPv6 or IPv4 is fine.
       2001:4860:4860::8888;
       2001:4860:4860::8844;

       8.8.8.8;
       8.8.4.4;
    };

   dnssec-enable yes;
   dnssec-validation auto;

   allow-query { any; };
   allow-query-cache { home-net; };
   allow-recursion { home-net; };
};

zone "subdomain.example.net" {
    type forward;
    forward only;

    forwarders 
    { 
       # SAMBA PDC1 (Active Directory)
       2000:db8:cafe:100::1;
    
       # SAMBA PDC2 (Active Directory)
       2000:db8:cafe:100::2;    
    };
};

As far as I understand:

Whenever I want to lookup a host registered un the subdomain subdomain.example.net the nameserver would then contact one of the two SAMBA PDC that I have listed in the forwarders section in the zone configuration.

The nameserver would in turn do DNSSEC validation to ensure that the two SAMBA PDC's is actually authorized to reply for requests to the domain subdomain.example.net.

If the reply from SAMBA PDC's cannot be validated through DNSSEC, then the name server will turn to Google DNS and ask if they can provide a DNSSEC validated response.

Now here is the problem:

As I understand there are no DNSSEC support in SAMBA neither through using SAMBA INTERNAL_DNS or through BIND9_DLZ hence you cannot ever do DNSSEC validation on any zones maintained by SAMBA.

As far I understand there are 3 options:

• Disable DNSSEC validation globally.
• Use negative trust anchors.
• Use the 'validate-except' option.

I will handle them one by one.

Disable DNSSEC

It is not really an option in my book. It basically reduces your setup to "works worldwide" ... except you particular small corner of the world, so better disable it alltogether.

It can be done by just changing the value of dnssec-enable and dnssec-validation to no.

I will only use it as a temporary fix until I can activate DNSSEC again.

Use negative trust anchors

At first my interest was peaked. The idea is you register a special encrypted key with rndc and then it won't do any DNSSEC validation for the domain you want.

However it is a temporary fix, since the key has a lifetime of at most one week.

That means you have todo the same kind of sourcery as certificates from Let's Encrypt - only that the cron job have to be triggered more often.

Use the 'validate-except' option

In theory this should be the easiest solution of them all.

I just have to add a new section to options called validate-except.

Like so:

options
{

   dnssec-enable yes;
   dnssec-validation auto;

   validate-except
   {
       "subdomain.example.net";
       "another.example.net";
   };
};

Sounds simple enough - right? :-)

... Except my nameserver didn't start due to "unknown option - validate-except".

EDIT: Turn out Raspberry OS uses Bind version 9.11 while the validate-except option was only implemented in Bind version 9.13.

For reference sake Ubuntu 20.04 for Raspberry uses Bind version 9.16.

So does anyone out there have experience with a mixed mode setup regarding DNSSEC?

... or would the easiest solution be admit failure and install Ubuntu 20.04? :-)

I have a device running Samba as an Active Directory Domain Controller using BIND_DLZ as a backend.

On top of that I am running a secondary device also configured as an Active Directory Domain Controller also with BIND_DLZ as backend for redundancy purpose.

IP addresses are assigned by ISC DHCP server which are able to update DNS ressource records using an ecryption key (TSIG).

Anyway: Onto my problem.

Here is my current setup

named.conf.options:

options 
{
     directory "/var/cache/bind";

     forwarders {
            2001:4860:4860::8888;
            2001:4860:4860::8844;
            8.8.8.8;
            8.8.4.4;
     };

     auth-nxdomain no;    # conform to RFC1035
     listen-on-v6 { any; };

     listen-on port 53 { 192.168.1.240; };
     listen-on port 5353 { 127.0.0.1; }; <-- Used for Netflix IPv6 filter only.

     tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
     minimal-responses yes;
     recursion yes;
};

acl "home-net"
{
    127.0.0.1;
    192.168.1.0/24;
    2001:db8:cafe:beef::/56; # <-- I am using a IPv6 range from Tunnelbroker in real life.
};

view "normal"
{
    include "/etc/bind/named.conf.default-zones";
    include "/etc/bind/named.conf.internal";

    # Netflix really dislike Tunnelbroker IPv6, so I am dropping any Netflix AAAA ressources records.
    include "/etc/bind/netflix-ipv6-blackhole.conf";  

    match-clients
    {
        home-net; # <-- Only respond to queries originating from my own network.
    };

    dnssec-enable yes;
    dnssec-validation auto;

    allow-query { any; };
    allow-query-cache { home-net; };
    allow-recursion { home-net; };

    forwarders {
      8.8.8.8;
      8.8.4.4;
      2001:4860:4860::8888;
      2001:4860:4860::8844;
   };
};

named.conf.internal:

zone "1.168.192.in-addr.arpa"
{
    type master;
    file "/etc/bind/db.192.168.1.rev";
    notify yes;

    allow-query { any; };
    allow-transfer { xfer; };

    # If allow-update is enabled instead of the include named.conf.update line, 
    # then Dynamic DNS works fine due to ISC DHCP can update the ressource records. 
    #
    # Sadly you can't have both lines enabled. It is either / or.

    // allow-update { key ddns-key; };

    include "/var/lib/samba/bind-dns/named.conf.update"; # <-- Having issues with THIS line only.
};

include "/var/lib/samba/bind-dns/named.conf";

/var/lib/samba/bind-dns/named.conf:

dlz "AD DNS Zone" {
    # For BIND 9.11.x
    database "dlopen /usr/lib/arm-linux-gnueabihf/samba/bind9/dlz_bind9_11.so";
};

/var/lib/samba/bind-dns/named.conf.update:

/* this file is auto-generated - do not edit */
update-policy {
        grant EXAMPLE.COM ms-self * A AAAA;
        grant [email protected] wildcard * A AAAA SRV CNAME;

        # Main Active Directory Domain Controller
        grant [email protected] wildcard * A AAAA SRV CNAME;

        # Backup Active Directory Domain Controller
        grant [email protected] wildcard * A AAAA SRV CNAME;
};

If I try to start bind with this configuration I will get a rather odd error that I cannot figure out:

/var/lib/samba/bind-dns/named.conf.update:3: name field not set to placeholder value '.'

Is there anyone who can clue me into what is wrong with named.conf.update?

I am trying to debug my IPv6 network and ran into an issue that I can't understand.

I am using OpenVPN as my VPN server and here is a short diagram of the setup:

All packages are dropped, when I try to ping from VPN Client (2001:470:7875:1::2) to VPN Server (2001:470:7875:1::1), but here is the curious thing:

I can ping any other host over IPv6 (like Google) or any other VPN client connecting to the same VPN server over IPv6.

I can also ping my VPN server on its native IPv6 interface (ens3). It is only the VPN server interface (tun0) that does not respond when pinged directly.

Therefore I am wondering what is going on?

Since I have two IPv6 links to the IPv6 version of internet I have todo policy based routing. The rules are pretty simple.

• Only IPv6 packages that originates from VPN server itself are allowed to be sent over the native IPv6 link.
• All other IPv6 packages has to be handled by the Hurricane Electric IPv6 tunnel.

This leads my to the following routing table on the VPN server:

The command ip -6 rule show has the following setup:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

Table local:

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

Table main:

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

Table openvpn:

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

Is there anybody who can clue me in? :-)

A quick recap on the unreachable lines in routing table

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

The range of 2001:470:7875::/48 is from 2001:470:7875:0:0:0:0:0 to 2001:470:7875:ffff:ffff:ffff:ffff:ffff.

I have assigned the subnet 2001:470:7875:1::/64 to the VPN tunnel.

• 2001:470:7875:1::/64 is part of the 2001:470:7875::/48 subnet, which can leads to a conflict in the routing table.
• 2001:470:1f14:2c7::/64 is not a part of the 2001:470:7875::/48 subnet and therefore does not conflict with routing table.

No other IP range is in use, but will be at a undetermined later date.

Keeping in mind longest prefix wins gives us the following behaviour:

• Any IP packages for 2001:470:1f14:2c7::/64 subnet will be handled by he-ipv6 interface.
• Any IP packages for 2001:470:7875:1::/64 subnet will be handled by tun0 interface.
• All other IP packages for 2001:470:7875::/48 subnet will be replied back with unreachable.

Im kind of staring myself blind in how get ActiveSync to work correctly with my mailserver, so maybe anybody here have an idea?

The deal is mailserver is hosting four domains and I want that all sent mails have DKIM signature.

I have gotten it to work when sending via SMTP, but it fails signing when the client uses ActiveSync to send the email.

Anyway here is a diagram on how it works for SMTP:

Most of the magic in how Postfix descides how to identify mail sent from an authenticated user, which belongs to one of my hosted domains vs a mail from somewhere on the Internet comes from this line in /etc/postfix/main.cf:

smtpd_sender_restrictions = 
    check_sender_access regexp:/etc/postfix/tag_as_originating.re, 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, 
    check_sender_access regexp:/etc/postfix/tag_as_foreign.re

content_filter = amavis:[127.0.0.1]:10024

The content of /etc/postfix/tag_as_foreign.re:

/^/ FILTER amavis:[127.0.0.1]:10024

Amavis sent the result back to Postfix using port 10025 which is handled by /etc/postfix/master.cf with this configuration:

127.0.0.1:10025 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks, reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks, no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes

The content of /etc/postfix/tag_as_originating.re:

/^/ FILTER amavis:[127.0.0.1]:10026

The result is sent back to Postfix using port 10027 and handled by this code in /etc/postfix/master.cf:

127.0.0.1:10027 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks, reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks, no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o milter_default_action=accept
    -o milter_macro_daemon_name=ORIGINATING
    -o disable_dns_lookups=yes

Finally here is the relevant lines in master.cf on how mails get introduced to Postfix in first place:

smtp      inet  n       -       y       -       -       smtpd

pickup    unix  n       -       y       60      1       pickup

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated, reject

smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated, reject

I am using Z-push to handle connections via ActiveSync, but my issue is a follows:

I have noticed in the mail.log that even though stated in z-push config files that it should pass incomming mails to postfix via SMTP it still insist on putting incomming mails directly into maildrop directory which in turn is handled by Postfix pickup deamon.

From there the mail is either forwarded directly to destination address without even being DKIM signed by Amavis.

The question is: How can I get Postfix to pass mails from pickup daemon on to Amavis, so it can get a DKIM signature, before being forwarded to destination?

Is it as simple as just insert a line underneath pickup in master.cf with the text:

-o content_filter = amavis:[127.0.0.1]:10026

... or does the conflict with already existing setup? :-)

Trying to learn how IPv6 works with OpenVPN, so I wanted to setup following scheme.

I have a VPS server (Ubuntu), which have been allocated a /48 subnet.

ISP ipv6 gateway is XXXX:XXXX:XXXX::1
Server ipv6 address is XXXX:XXXX:XXXX:39::1

The idea is that any clients connecting to server gets an ip address on the XXXX:XXXX:XXXX:39:2::/64 subnet.

Server configuration file is based on the sample configuration from OpenVPN with the following additions:

dev tun
tun-ipv6
server-ipv6 XXXX:XXXX:XXXX:39:2::/64
push "route-ipv6 XXXX:XXXX:XXXX:39::/48"

Restarting OpenVPN server gave no problems.

Server is assigned following ip addresses:

eth0: XXXX:XXXX:XXXX:39::1/48
tun0: XXXX:XXXX:XXXX:39::2/64

Client is assigned:

OpenVPN tap: XXXX:XXXX:XXXX:39:2:0:1:0, and I can ping XXXX:XXXX:XXXX:39::1 just fine. However pinging ISP gateway from client makes connection time out.

I can ping ISP ipv6 gateway from server.

I have allowed traffic from XXXX:XXXX:XXXX:39:2::/64 in Ubuntu Firewall.

What am I missing?

I should mention server is running OpenVPN version 2.2.1 - is that the reason for the complaining?