# JWS has an invalid anti-replay nonce when client behind NAT **URL:** \ **Category:** Help\ **Created:** [July 11, 2018, 4:09pm UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493 "2018-07-11T16:09:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mcv21](https://avatars.discourse-cdn.com/v4/letter/m/7bcc69/32.png) [@mcv21](https://community.letsencrypt.org/u/mcv21)\ **Post date:** [July 11, 2018, 4:09pm UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493/1 "2018-07-11T16:09:56Z")
My domain is: [insee.sanger.ac.uk](http://insee.sanger.ac.uk) I ran this command: dehydrated -c -x It produced this output: - Responding to challenge for [insee.sanger.ac.uk](http://insee.sanger.ac.uk) authorization… - ERROR: An error occurred while sending post-request to [https://acme-staging-v02.api.letsencrypt.org/acme/challenge/5jY4YYWmTOkHpuwECsJpm0BRzSSophv\_\_fd9-AWAXBg/147168375](https://acme-staging-v02.api.letsencrypt.org/acme/challenge/5jY4YYWmTOkHpuwECsJpm0BRzSSophv__fd9-AWAXBg/147168375) (Status 400) Details: HTTP/1.0 200 Connection established HTTP/1.1 100 Continue Expires: Wed, 11 Jul 2018 15:58:20 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache HTTP/1.1 400 Bad Request Server: nginx Content-Type: application/problem+json Content-Length: 169 Boulder-Requester: 6437202 Replay-Nonce: Wk4kKi6k9\_G2wPiyUxT9VM4ght0O8PBdNYaF\_p0p1t8 Expires: Wed, 11 Jul 2018 15:58:20 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Wed, 11 Jul 2018 15:58:20 GMT Connection: close { “type”: “urn:ietf:params:acme:error:badNonce”, “detail”: "JWS has an invalid anti-replay nonce: “n6hlVrPXGmkIxODJD3Heu2BKeAEwieVhdC6UUacoeE4"”, “status”: 400 } My web server is (include version): civetweb (from ceph), but this is the DNS-validation protocol The operating system my web server runs on is (include version): Ubuntu 16.04 I can login to a root shell on my machine (yes or no, or I don’t know): yes I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no Hi, I’m using the DNS-challenge based approach, and I think this is a problem because I’m behind NAT (with many different IP addresses) - I see @jsha saying [here](https://community.letsencrypt.org/t/jws-has-invalid-anti-replay-nonce-since-tonight-june-4th/35462/7) that this can be an issue. Is there a workaround for where my client is behind NAT? Even retrying repeatedly doesn’t help, and if I do the same from my workstation rather than the server, then I’m always NATed to the same address and don’t see this problem. But for production, we want to run the dehydrated client on the production machines, which are behind multi-IP NAT; this is unlikely to be a very unusual config, so I’m bit surprised that letsencypt has a problem with it… Thanks, Matthew ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [July 12, 2018, 12:29am UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493/2 "2018-07-12T00:29:33Z")
Boulder still does not share the nonce pool between instances of itself, and (appears to) rely on source IP stickyness to ensure your requests go to the same Boulder server. So if you are making outgoing requests using different IPs, there’s a chance that your connections will go to different Boulder instances. Unless you can configure outgoing sticky NAT, you might need to proxy your requests via an external host. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [July 16, 2018, 9:22pm UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493/3 "2018-07-16T21:22:04Z")
@_az is correct. dehydrated is a shell script that runs a separate curl command for each request, which means each request is made on a new connection, which means you get assigned a new source IP address. Most likely a client that reuses an HTTPS connection over multiple requests would have much less trouble. That rules out shell-based clients, but other clients should work reasonably well. ---
**Author:** ![mcv21](https://avatars.discourse-cdn.com/v4/letter/m/7bcc69/32.png) [@mcv21](https://community.letsencrypt.org/u/mcv21)\ **Post date:** [July 17, 2018, 8:28am UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493/4 "2018-07-17T08:28:27Z")
Thanks for clarifying; perhaps this could be more clearly flagged in the FAQ or similar? ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [August 16, 2018, 8:28am UTC](https://community.letsencrypt.org/t/jws-has-an-invalid-anti-replay-nonce-when-client-behind-nat/66493/5 "2018-08-16T08:28:27Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.