Messages

Hi,
I'm using rsync over ssh to copy opnsense configuration from /conf to another host.

Just dropped a shell script to opnsense:/usr/local/etc/periodic/daily

Code Select Expand

#!/bin/sh
PATH=$PATH:/usr/local/bin:/usr/local/sbin
export PATH

/usr/local/bin/rsync -av /conf server:/backups/opnsense


You may need to install rsync via pkg add rsync and setup puplic-key authentication for user root.

Hi,
still have that problem. Today I will update this box to 17.7.4, but I don' think this will help (from reading the changelog).

Since I cannot see any error in logfiles and because restarting unbound always means service interruption of about 2-3 seconds I am using this script to manually reload the unbound:

Code Select Expand

#!/bin/sh
echo "

<?php require_once ('services.inc'); require_once ('util.inc'); killbypid('/var/run/unbound.pid', 'HUP'); exit; ?>

"  | /usr/local/bin/php -q


This will make unbound read /var/unbound/dhcpleases.conf.

Could this be a configuration problem?

Is anyone using dhcp server and unbound on his box and has working DNS resolution of dhcp clients?

I have set unbound to "Register DHCP leases in the DNS Resolver" and "Register DHCP static mappings in the DNS Resolver" but are unable to resolve new dhcp leases.

What I found so far is, that /var/unbound/dhcpleases.conf is written and data is ok. Simply restarting unbound will help to resolve new hosts from dhcpleases.conf.
It seems that unbound is not triggered to read the changed file.

The box is currently running 17.7.3.

This is unbound config:

Code Select Expand


  <unbound>
    <custom_options>include:/var/unbound/conf.d/ad-blacklist.conf</custom_options>
    <forwarding>1</forwarding>
    <regdhcp>1</regdhcp>
    <regdhcpstatic>1</regdhcpstatic>
    <active_interface/>
    <outgoing_interface/>

### snip
host entries
### snip

    <hideidentity>1</hideidentity>
    <hideversion>1</hideversion>
    <cache_max_ttl/>
    <cache_min_ttl/>
    <incoming_num_tcp>10</incoming_num_tcp>
    <infra_cache_numhosts>10000</infra_cache_numhosts>
    <infra_host_ttl>900</infra_host_ttl>
    <jostle_timeout>200</jostle_timeout>
    <log_verbosity>1</log_verbosity>
    <msgcachesize>4</msgcachesize>
    <num_queries_per_thread>512</num_queries_per_thread>
    <outgoing_num_tcp>10</outgoing_num_tcp>
    <unwanted_reply_threshold/>
    <enable>1</enable>
    <acls>
      <aclname>nt0010 openvpn adress</aclname>
      <aclaction>allow</aclaction>
      <description>nt0010 openvpn adress</description>
      <row>
        <acl_network>172.16.1.2</acl_network>
        <mask>32</mask>
        <description>nt0010 openvpn adress</description>
      </row>
    </acls>
    <acls>
      <aclname>Openvpn Clients</aclname>
      <aclaction>allow</aclaction>
      <description/>
      <row>
        <acl_network>172.16.7.0</acl_network>
        <mask>24</mask>
        <description/>
      </row>
    </acls>
  </unbound>


Updating to 17.7.1 fixed it! Thx a lot for that update!

Ping on console also works as expected:

root@opnsense:~ # tcpdump -n -i igb0_vlan513 host 193.99.144.85 &
[1] 2966
root@opnsense:~ # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0_vlan513, link-type EN10MB (Ethernet), capture size 262144 bytes

root@opnsense:~ #
root@opnsense:~ #
root@opnsense:~ # ping -S 10.2.2.3 193.99.144.85
PING 193.99.144.85 (193.99.144.85) from 10.2.2.3: 56 data bytes
07:24:47.322036 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 37439, seq 0, length 64
07:24:47.367752 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 37439, seq 0, length 64
64 bytes from 193.99.144.85: icmp_seq=0 ttl=248 time=46.071 ms
07:24:48.330244 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 37439, seq 1, length 64
07:24:48.379195 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 37439, seq 1, length 64
64 bytes from 193.99.144.85: icmp_seq=1 ttl=248 time=49.127 ms
07:24:49.338332 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 37439, seq 2, length 64
07:24:49.386903 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 37439, seq 2, length 64
64 bytes from 193.99.144.85: icmp_seq=2 ttl=248 time=48.761 ms
07:24:50.339520 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 37439, seq 3, length 64
07:24:50.388825 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 37439, seq 3, length 64
64 bytes from 193.99.144.85: icmp_seq=3 ttl=248 time=49.403 ms
^C
--- 193.99.144.85 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 46.071/48.340/49.403/1.330 ms


No I can reinstall the old pfsense box with opnsense and have a backup router. :-)

Thx, I will try that and report back.

I'm still struggeling with this issue. Currently my old pfsense box is running to just update my Freedns entries.

I did a quick test with vanilla FreeBSD 11.1, two interfaces and curl using --interface parameter: it didn't work. Could this have been introduced with FreeBSD 11? Didn't had time yet to check with vanilla FreeBSD 10/older OPNsense releases.

If somebody is using 17.7 and dyndns package to update multiple dynamic DNS entries with multiwan, please respond. :-)

Just another note: in the gui is "diag_ping.php" which allows to select a source address for icmp echo.

But the source address is not honored and the traffic goes out the default route interface.

Checked it on the commandline like that:

One of the WAN interfaces:

Code Select Expand


root@opnsense:~ # ifconfig igb0_vlan513 inet
igb0_vlan513: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 10.2.2.3 netmask 0xffffff00 broadcast 10.2.2.255


Set up tcpdump to see where traffic is going

Code Select Expand


root@opnsense:~ # tcpdump -n -i igb0_vlan513 host 193.99.144.85 &


Ping internet host:

Code Select Expand


root@opnsense:~ # ping -S 10.2.2.3 193.99.144.85
PING 193.99.144.85 from 10.2.2.3: 56 data bytes       
64 bytes from 193.99.144.85: icmp_seq=0 ttl=251 time=23.956 ms       
64 bytes from 193.99.144.85: icmp_seq=1 ttl=251 time=24.151 ms       
64 bytes from 193.99.144.85: icmp_seq=2 ttl=251 time=23.394 ms       
64 bytes from 193.99.144.85: icmp_seq=3 ttl=251 time=23.649 ms       
64 bytes from 193.99.144.85: icmp_seq=4 ttl=251 time=24.501 ms       


But I see no traffic. Instead this shows where traffic is going:

Code Select Expand


root@opnsense:~ # tcpdump -n -i igb0_vlan515 host 193.99.144.85 &
PING www.heise.de (193.99.144.85) from 10.2.2.3: 56 data bytes                                                                             
14:01:02.952654 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 31320, seq 0, length 64                                                 
14:01:02.977134 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 31320, seq 0, length 64                                                   
64 bytes from 193.99.144.85: icmp_seq=0 ttl=251 time=24.639 ms                                                                             
14:01:03.966262 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 31320, seq 1, length 64                                                 
14:01:03.990216 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 31320, seq 1, length 64                                                   
64 bytes from 193.99.144.85: icmp_seq=1 ttl=251 time=24.284 ms                                                                             
14:01:04.980931 IP 10.2.2.3 > 193.99.144.85: ICMP echo request, id 31320, seq 2, length 64                                                 
14:01:05.005350 IP 193.99.144.85 > 10.2.2.3: ICMP echo reply, id 31320, seq 2, length 64                                                   
64 bytes from 193.99.144.85: icmp_seq=2 ttl=251 time=24.632 ms           


And this is the default route:

Code Select Expand


root@nt0002:~ # route show default
   route to: default
destination: default
       mask: default
    gateway: nt0028
        fib: 0
  interface: igb0_vlan519
      flags: <UP,GATEWAY,DONE,STATIC>
recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0


So dyndns IP checking and this diagnostic ping behave differently than expected? I searched github for any notes on localhost route selection / traffic originating from the firewall but did not find help. Could it be something with the 17.7 release?

I digged around a bit and dyndns plugin seems to use curl for updating (see https://github.com/opnsense/plugins/tree/master/dns/dyndns) and checking the required IPs.

In /usr/local/etc/services.inc there is "function get_dyndns_ip" which seems to use curls "--interface" option.

I tried it manually on the pfsense box like that:

Code Select Expand

curl -v --interface x.x.x.x "http://checkip.dyndns.org"
where x.x.x.x was replaced with the interface IPs of the WAN interfaces.

The result is always the WAN ip from the default route.

So yes, it is a routing problem. Can it be solved?

Hate to say: this used to work on a pfsense 2.3 box I replaced yesterday.

Hi,

I have a multi-wan setup with 3 next hop router and want to update 3 freedns records based on those routers wan IPs.

This is what I have configured 3 times (see screenshot), each with its unique hostname and with the "interface to monitor" set to the corresponding interface.

But all records are updated with the IP adresse from the default route and not the different wan ips.

The logs say this:

Code Select Expand


Aug 9 21:17:30 opnsense: /services_dyndns_edit.php: Dynamic DNS (myfreedns.hostname): (Success) IP Address Changed Successfully!
Aug 9 21:17:30 opnsense: /services_dyndns_edit.php: Dynamic DNS: updating cache file /var/cache/dyndns_opt2_myfreedns.hostname_0.cache: 80.62.134.xxx


The box is running
OPNsense 17.7-amd64
FreeBSD 11.0-RELEASE-p11


Any ideas?
LibreSSL 2.4.5