1
23.7 Legacy Series / Re: Newest os-acme-client/acme.sh, DNS service "INWX XMLRPC" missing OTP seed field
« on: October 17, 2023, 10:36:45 am »
Thanks, added a comment to that thread.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
23.7 Legacy Series / Newest os-acme-client/acme.sh, DNS service "INWX XMLRPC" missing OTP seed field
« on: October 17, 2023, 03:02:43 am »
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:
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:
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!
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]
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]
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!
3
General Discussion / Re: UDP Broadcast Relay
« on: April 04, 2021, 11:40:49 pm »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]
pass in quick on igb0_vlan1042 inet proto udp from {10.10.42.16} to {10.10.42.1} port {1900} keep stateOr in config/XML style:
Code: [Select]
<?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]
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:
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.
4
General Discussion / Re: UDP Broadcast Relay
« on: April 04, 2021, 05:43:46 am »
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:
Matching rules are in place:
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.
I'd expect the replicated response back in DIAL clients' net to go something like:
Instead the replicated response looks like
DIAL server at .42.16 gets the request and sends its response, tcpdump confirms it's got what looks like proper content.
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.
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]
udpbroadcastrelay --id 4 --port 1900 --dev igb0_vlan1060 --dev igb0_vlan1042 -s 1.1.1.1 --multicast 239.255.255.250 -dMatching rules are in place:
Code: [Select]
# 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 stateNow 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]
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]
-> [ 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]
-> [ 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]
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.
Pages: [1]