Messages

Thanks, added a comment to that thread.

Newest os-acme-client/acme.sh, DNS service "INWX XMLRPC" missing OTP seed field

Hi all,

on newest OPNsense 23.7.6, newest os-acme-client 3.19 and newest acme.sh 3.0.7_1 the DNS provider INWX XMLRPC (INWX being a Germany-based domain name registrar at inwx.de) allows entering a username and password for authentication. I think this wasn't always the case, I'm kinda missing an optional third field to add a "shared secret" (in acme.sh language), this is an RFC6238 one-time password seed aka Google Authenticator seed.

Can I rubber duck-debug my thought process here with you before I go out and file a bug report? Since 21.1 times I've had auto-renewal of OPNSense's own web GUI cert with os-acme-client via DNS-01 challenge against my INWX account configured and since forever ago that account has had one-time password authentication enabled. There is no optional OTP-less access to INWX' API so if the account itself has it ACME clients must use it as well. Renewal last correctly worked on August 1 of this year, at that time the OPNsense installation was still on 21.1. 60 days later on September 30 renewal failed. I didn't look at errors at the time, I figured I might just get on with an upgrade to newest OPNsense 23.7.6 along with os-acme-client and acme.sh.

With everything now up to date I'm seeing similar behavior as before. In "Services: ACME Client: Settings" I did "Reset ACME Client". A manual renew attempt correctly finds '/usr/local/share/examples/acme.sh/dnsapi/dns_inwx.sh', issues an error 'INWX API: Mobile TAN detected. Please define a shared secret.' and quits. Per 'dns_inwx.sh' this only happens if during script execution the environment variable $INWX_Shared_Secret is unset or set to an empty string.

I looked up previous errors that had been happening nightly since September 30, those all reported 'INWX API: Mobile TAN not correct.' which only happens if a $INWX_Shared_Secret value is set, used to generate a one-time password and in our HTTP response body we're not finding:

Code Select Expand

grep -- '<member><name>code</name><value><int>1000</int></value></member>'

Since this might just be a grep issue I thought it could be forum topic 36087 or opnsense/plugins issue #3590 waiting for official acme.sh commit 9143cd1 to become available in OPNsense. That wasn't it though, the commit made it into acme.sh-3.0.7_1.pkg on last Thursday, October 12 per fichtner's opnsense/plugins issue #3590 comment 1758942032. Also it did touch an unrelated file.

So erm ... how did I renew SSL certs against INWX' API with a Google Auth seed for two years when such a Google Auth seed cannot be entered in os-acme-client settings menu? I've been very hands-off of my OPNsense installation for a while, I also didn't document anything fancy back when I last set up cert renewal. Whatever I did surely wasn't so egregious as to manually insert a hard-coded string into the acme.sh renewal script. I hope. Did I do what this person did and this person did and manually add a variable to '/usr/local/etc/pkg.conf'? If so why were my changes - presumably - reverted between last successful renewal on August 1 and first renew failure on September 30 without me doing a package upgrade? I did try just now for fun to add this to the file and rebooted:

Code Select Expand

PKG_ENV {
    INWX_Shared_Secret: "rfc6238-otp-seed-here"
}

Whatever PKG_ENV is it's apprently not an environment available to packages in the sense that I think it it; the ACME renew process still reports 'Please define a shared secret.' so whatever I did there isn't helpful and I reverted this file to defaults.

Is there something in os-acme-client that I'm missing to provide arguments not configurable via the OPNsense web frontend? Was there ever an option for INWX XMLRPC shared secrets? In plugin code I'm not seeing anything, I'm at a bit of a loss.

Any help and rubber duck debug review is greatly appreciated, thanks!

[out]

The reply packet is not 239.255.255.250, try adding a specific rule to allow the reply packets to get back to the LAN where the client is.

I temporarily removed all restrictions except for port 1900 and got a match just as well so I'm almost sure the old rule was sufficient as well:

Code Select Expand

pass in quick on igb0_vlan1042 inet proto udp from {10.10.42.16} to {10.10.42.1} port {1900} keep state

Or in config/XML style:

Code Select Expand

<?xml version="1.0"?>
<opnsense>
  <filter>
    <rule>
      <type>pass</type>
      <interface>opt10</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>udp</protocol>
      <source>
        <address>10.10.42.16</address>
      </source>
      <destination>
        <address>10.10.42.1</address>
        <port>1900</port>
      </destination>
    </rule>
  </filter>
</opnsense>

One curious thing I noticed is that the TV sends SSDP response packets to 10.10.42.1.1900 which then show up on interface lo0. File '/var/log/filter.log' confirms:

Code Select Expand

Apr  4 21:09:33 fw-a filterlog[33972]: 123,,,0,lo0,match,pass,out,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
Apr  4 21:09:33 fw-a filterlog[33972]: 122,,,0,lo0,match,pass,in,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
So first these response packets come out of the firewall into lo0, then go in to the firewall never to emrge again - at least not according to tcpdump.

Firewall log live view shows the first out with comment "let out anything from firewall host itself", the in with comment "pass loopback":


At the end of the day if I'm being particularly dense here I can always link Youtube smartphone apps with the TV via the Watch YouTube on TV with a TV code feature; I'm guessing that just establishes comms via YouTube's servers.

Am I missing something obvious? Anything I should be trying?

//edit: Oh I also played around with port forwards and outbound NATting for packets to show up where I'm guessing the Youtube smartphone app is expecting them. Didn't do me any good so far. While testing over time I've seen the TV send out four different types of HTTP NOTIFY requests (also all via 239.255.255.250:1900). It's letting everyone kow that it has:

• http://10.10.42.16:7678/nservice/
• http://10.10.42.16:7676/rcr/
• http://10.10.42.16:9119/screen_sharing
• http://10.10.42.16:9197/dmr

I haven't seen the Youtube smatphone app try to reach any one of those endpoints once so I'm pretty sure it doens't care about those specific SSDP replies.

Great piece of software, has helped me getting a multi-function device discovered across VLANs. I have a situation with a smart TV now that I can't quite solve. Maybe you can point me in the right direction.

I have a 2017 Samsung TV so it implements the Google Cast/Chromecast built-in predecessor Discovery and Launch (DIAL), specs for reference. Essentially DIAL clients such as the Youtube app on a smartphone use Simple Service Discovery Protocol to 239.255.255.250 on UDP port 1900.

From udpbroadcastrelay's side I'm using:

Code Select Expand

udpbroadcastrelay --id 4 --port 1900 --dev igb0_vlan1060 --dev igb0_vlan1042 -s 1.1.1.1 --multicast 239.255.255.250 -d

Matching rules are in place:

Code Select Expand

# DIAL clients net (smartphones and their Youtube apps live here)
pass in quick on igb0_vlan1060 inet proto udp from {(igb0_vlan1060:network)} to {239.255.255.250} port {1900} keep state

# Entertainment net (TV implementing a DIAL server lives here)
pass in log quick on igb0_vlan1042 inet proto udp from {(igb0_vlan1042:network)} to {10.10.42.1} port {1900} keep state

Now when a DIAL client sends SSDP requests, here's the output of udpbroadcastrelay that I'm a bit confused by. In this example the client's at 10.10.60.100, the DIAL server at 10.10.42.16.

Code Select Expand

ID set to 4
Port set to 1900
Outgoing source IP set to 1.1.1.1
ID: 4 (DSCP: 4, ToS: 0x10), Port 1900
igb0_vlan1060: 12 / 10.10.60.1 / 10.10.60.255
igb0_vlan1042: 19 / 10.10.42.1 / 10.10.42.255
found 2 interfaces total
IP_ADD_MEMBERSHIP:              10.10.60.1 239.255.255.250
IP_ADD_MEMBERSHIP:              10.10.42.1 239.255.255.250
Done Initializing

<- [ 10.10.60.100:40536 -> 239.255.255.250:1900 (iface=12 len=125 tos=0x00 DSCP=0 ttl=1)
-> [ 10.10.42.1:1900 -> 239.255.255.250:1900 (iface=19 len=125 tos=0x10 DSCP=4 ttl=1)

<- [ 10.10.42.16:41954 -> 10.10.42.1:1900 (iface=19 len=411 tos=0x00 DSCP=0 ttl=64)
-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

<- [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=5 len=411 tos=0x10 DSCP=4 ttl=64)
IP DSCP (4) matches ID. IP ToS 0x10. Packet Ignored.

I'd expect the replicated response back in DIAL clients' net to go something like:

Code Select Expand

-> [ 10.10.60.1:1900 -> 239.255.255.250:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

Instead the replicated response looks like

Code Select Expand

-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)

DIAL server at .42.16 gets the request and sends its response, tcpdump confirms it's got what looks like proper content.

Code Select Expand

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
    CACHE-CONTROL: max-age=1800\r\n
    DATE: Sun, 04 Apr 2021 02:58:36 GMT\r\n
    EXT: \r\n
    LOCATION: http://10.10.42.16:7678/nservice/\r\n
    SERVER: Samsung-Linux/4.1, UPnP/1.0, Samsung_UPnP_SDK/1.0\r\n
    ST: urn:dial-multiscreen-org:service:dial:1\r\n
    USN: uuid:7bbede11-cb5a-4c60-b356-ab6914661a7f::urn:dial-multiscreen-org:service:dial:1\r\n
    WAKEUP: MAC=9c:8c:6e:00:00:02;Timeout=10\r\n
    Content-Length: 0\r\n
    BOOTID.UPNP.ORG: 9\r\n
    \r\n
    [HTTP response 1/1]

In DIAL clients net that response is never seen. Am I missing something obvious why the reply packet apparently doesn't get replicated back into the DIAL client's net?

//edit: Similar to Chromecast in later versions I only get a response at all by using source address 1.1.1.1. I also tried '--ttl-id' for fun, it increased the TTL header as outlined in the manual, behavior itself was the same.