I ran a port scan of my public ip and found ports that I had not opened (forwarded) to be open

so today I was attempting to demonstrate something for a friend, so I ran a port scan of my public ip, of my home network, and found ports that I had not opened (forwarded)to be open. I am on optimum online, could this just be them messing with my network or is this something to be worried about? how can I go about figuring out what services are on those ports? is it worth trying to talk to someone at optimum? attached is an image of my port scan, and of my router’s config page to show the differences.

the ports in question are 3394, 5473, and 18017

enter image description here

Router config page Thanks for the help.

NGINX: determining what port a request forwarded by an AWS load balancer was originally sent to

I want a set-up where an Amazon load balancer forwards requests received on any of port 21001, 21002 and 21003 and send them all to an NGINX reverse-proxy on port 443 (regardless) which in turn forwards the request to a member of a cluster by IP address. Is there a directive I can include in an nginx.conf to determine the port that the original request was sent to in order to route this? X-Forwarded-Proto seems close, but only determines between https and http, not arbitrary high TCP ports.

Gmail forwarded email that can be readily replied to the original sender?

A sends an email to B who finds the email is meant for C. So B forwarded the A’s email to C by Gmail forwarding.

C receives A’s email from B, types something and clicks reply. Now B receives C’s reply instead of A. Unless C explicitly changes the TO address of the reply which is very unintuitive and most of the time we just forgot it.

Is there any way for B to forward the email to C so C and A can immediately communicate with each other? How to forward an email so the reply goes directly to the original sender in Gmail?

OpenVPN over stunnel not working when forwarded through router but working internally

I’m trying to set up OpenVPN over stunnel on my personal server.

openvpn is in tcp and connects fine outside of stunnel, even when connecting through a port forward on the router.

OpenVPN wrapped in stunnel works fine when not connecting through the port forward on the router, i.e. stunnel sends to internal IP address.

stunnel appears to be working fine when connecting through a forwarded port on the router, I set up an stunnel for SSH and that connects fine, I even left it in a while loop outputting to the console for a couple of minutes to see if if would fail.

However, when running openVPN over stunnel and through a port forward on the router the connection appear to set up but then drops and I can’t get web traffic.

I’ve been debugging this all day and any help would be hugely appreciated.

I get the following warnings in the OVPN log:

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1552', remote='link-mtu 1544' WARNING: 'cipher' is used inconsistently, local='cipher AES-256-GCM', remote='cipher BF-CBC' WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1' WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' 

stunnel settings server (included ssh test):

[openvpn] accept = 44444 connect = 127.0.0.1:1194 ciphers = DHE-RSA-AES256-SHA256  [sslssh] accept = 55555 connect = 127.0.0.1:22 

stunnel settings client:

[openvpn]

client = yes accept = 127.0.0.1:11194 connect = <my_ip>:44444 ;cert = /usr/local/etc/stunnel/cert.pem ;connect = 192.168.255.25:44444 ciphers = DHE-RSA-AES256-SHA256  [sslssh] client = yes accept  = 127.0.0.1:2222 connect = <my_IP>:55555 

client ovpn config:

remote localhost 11194 proto tcp remote-cert-tls server   client dev tun resolv-retry infinite keepalive 10 120 nobind comp-lzo verb 3 

server ovpn config :

port 1194 proto tcp dev tun  comp-lzo keepalive 10 120  persist-key persist-tun user nobody group nogroup  chroot /etc/openvpn/easy-rsa/keys/crl.jail crl-verify crl.pem  ca /etc/openvpn/easy-rsa/keys/ca.crt dh /etc/openvpn/easy-rsa/keys/dh2048.pem tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 key /etc/openvpn/easy-rsa/keys/server.key cert /etc/openvpn/easy-rsa/keys/server.crt  ifconfig-pool-persist /var/lib/openvpn/server.ipp client-config-dir /etc/openvpn/server.ccd status /var/log/openvpn/server.log verb 4 

full ovpn client log

2019-05-27 14:10:53 *Tunnelblick: openvpnstart starting OpenVPN *Tunnelblick: OS X 10.14.6; Tunnelblick 3.7.5a (build 5011); prior version 3.4.0 (build 4007) 2019-05-27 14:10:53 *Tunnelblick: Attempting connection with mikewarde_tcp_stunnel using shadow copy; Set nameserver = 769; monitoring connection 2019-05-27 14:10:53 *Tunnelblick: openvpnstart start mikewarde_tcp_stunnel.tblk 1337 769 0 1 0 1065264 -ptADGNWradsgnw 2.4.4-openssl-1.0.2o 2019-05-27 14:10:54 *Tunnelblick: openvpnstart log:      OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):            /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.4-openssl-1.0.2o/openvpn           --daemon           --log           /Library/Application Support/Tunnelblick/Logs/-SUsers-Smikewarde-SLibrary-SApplication Support-STunnelblick-SConfigurations-Smikewarde_tcp_stunnel.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1065264.1337.openvpn.log           --cd           /Library/Application Support/Tunnelblick/Users/mikewarde/mikewarde_tcp_stunnel.tblk/Contents/Resources           --setenv           IV_GUI_VER           "net.tunnelblick.tunnelblick 5011 3.7.5a (build 5011)"           --verb           3           --config           /Library/Application Support/Tunnelblick/Users/mikewarde/mikewarde_tcp_stunnel.tblk/Contents/Resources/config.ovpn           --verb           3           --cd           /Library/Application Support/Tunnelblick/Users/mikewarde/mikewarde_tcp_stunnel.tblk/Contents/Resources           --management           127.0.0.1           1337           /Library/Application Support/Tunnelblick/fognhooiggkindigaihckcifckpilcfpnmgdikmh.mip           --management-query-passwords           --management-hold           --script-security           2           --up           /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw           --down           /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw  2019-05-27 14:10:54 *Tunnelblick: Established communication with OpenVPN 2019-05-27 14:10:54 OpenVPN 2.4.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Mar 27 2018 2019-05-27 14:10:54 library versions: OpenSSL 1.0.2o  27 Mar 2018, LZO 2.10 2019-05-27 14:10:54 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337 2019-05-27 14:10:54 Need hold release from management interface, waiting... 2019-05-27 14:10:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337 2019-05-27 14:10:54 MANAGEMENT: CMD 'pid' 2019-05-27 14:10:54 MANAGEMENT: CMD 'state on' 2019-05-27 14:10:54 MANAGEMENT: CMD 'state' 2019-05-27 14:10:54 MANAGEMENT: CMD 'bytecount 1' 2019-05-27 14:10:54 MANAGEMENT: CMD 'hold release' 2019-05-27 14:10:54 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2019-05-27 14:10:54 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2019-05-27 14:10:54 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2019-05-27 14:10:54 MANAGEMENT: >STATE:1558962654,RESOLVE,,,,,, 2019-05-27 14:10:54 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:11194 2019-05-27 14:10:54 Socket Buffers: R=[131072->131072] S=[131072->131072] 2019-05-27 14:10:54 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11194 [nonblock] 2019-05-27 14:10:54 MANAGEMENT: >STATE:1558962654,TCP_CONNECT,,,,,, 2019-05-27 14:10:55 TCP connection established with [AF_INET]127.0.0.1:11194 2019-05-27 14:10:55 TCP_CLIENT link local: (not bound) 2019-05-27 14:10:55 TCP_CLIENT link remote: [AF_INET]127.0.0.1:11194 2019-05-27 14:10:55 MANAGEMENT: >STATE:1558962655,WAIT,,,,,, 2019-05-27 14:10:55 MANAGEMENT: >STATE:1558962655,AUTH,,,,,, 2019-05-27 14:10:55 TLS: Initial packet from [AF_INET]127.0.0.1:11194, sid=c58c277c 5918dc12 2019-05-27 14:10:55 VERIFY OK: depth=1, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=vpn@radged.com 2019-05-27 14:10:55 VERIFY KU OK 2019-05-27 14:10:55 Validating certificate extended key usage 2019-05-27 14:10:55 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2019-05-27 14:10:55 VERIFY EKU OK 2019-05-27 14:10:55 VERIFY OK: depth=0, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=vpn@radged.com 2019-05-27 14:10:55 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 2019-05-27 14:10:55 [server] Peer Connection Initiated with [AF_INET]127.0.0.1:11194 2019-05-27 14:10:57 MANAGEMENT: >STATE:1558962657,GET_CONFIG,,,,,, 2019-05-27 14:10:57 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 2019-05-27 14:10:57 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.222.29.1,topology net30,ping 10,ping-restart 120,ifconfig 10.222.29.6 10.222.29.5,peer-id 0,cipher AES-256-GCM' 2019-05-27 14:10:57 OPTIONS IMPORT: timers and/or timeouts modified 2019-05-27 14:10:57 OPTIONS IMPORT: --ifconfig/up options modified 2019-05-27 14:10:57 OPTIONS IMPORT: route options modified 2019-05-27 14:10:57 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified 2019-05-27 14:10:57 OPTIONS IMPORT: peer-id set 2019-05-27 14:10:57 OPTIONS IMPORT: adjusting link_mtu to 1627 2019-05-27 14:10:57 OPTIONS IMPORT: data channel crypto options modified 2019-05-27 14:10:57 Data Channel: using negotiated cipher 'AES-256-GCM' 2019-05-27 14:10:57 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2019-05-27 14:10:57 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2019-05-27 14:10:57 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16) 2019-05-27 14:10:57 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16) 2019-05-27 14:10:57 Opened utun device utun2 2019-05-27 14:10:57 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 2019-05-27 14:10:57 MANAGEMENT: >STATE:1558962657,ASSIGN_IP,,10.222.29.6,,,, 2019-05-27 14:10:57 /sbin/ifconfig utun2 delete                                         ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address 2019-05-27 14:10:57 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure 2019-05-27 14:10:57 /sbin/ifconfig utun2 10.222.29.6 10.222.29.5 mtu 1500 netmask 255.255.255.255 up 2019-05-27 14:10:57 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun2 1500 1555 10.222.29.6 10.222.29.5 init                                         **********************************************                                         Start of output from client.up.tunnelblick.sh                                         Disabled IPv6 for 'iPhone USB'                                         Disabled IPv6 for 'Wi-Fi'                                         Disabled IPv6 for 'Bluetooth PAN'                                         Disabled IPv6 for 'Thunderbolt Bridge'                                         Retrieved from OpenVPN: name server(s) [ 208.67.222.222 208.67.220.220 ], search domain(s) [  ] and SMB server(s) [  ] and using default domain name [ openvpn ]                                         WARNING: Ignoring ServerAddresses '208.67.222.222 208.67.220.220' because ServerAddresses was set manually and '-allowChangesToManuallySetNetworkSettings' was not specified                                         Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected                                         Saved the DNS and SMB configurations so they can be restored                                         Did not change DNS ServerAddresses setting of '1.1.1.1 1.0.0.1' (but re-set it)                                         Changed DNS SearchDomains setting from '' to 'openvpn'                                         Changed DNS DomainName setting from '' to 'openvpn'                                         Did not change SMB NetBIOSName setting of ''                                         Did not change SMB Workgroup setting of ''                                         Did not change SMB WINSAddresses setting of ''                                         DNS servers '1.1.1.1 1.0.0.1' were set manually                                         DNS servers '1.1.1.1 1.0.0.1' will be used for DNS queries when the VPN is active                                         NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.                                         Flushed the DNS cache via dscacheutil                                         /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil                                         Notified mDNSResponder that the DNS cache was flushed                                         Setting up to monitor system configuration with process-network-changes                                         End of output from client.up.tunnelblick.sh                                         ********************************************** 2019-05-27 14:11:00 *Tunnelblick: No 'connected.sh' script to execute 2019-05-27 14:11:00 /sbin/route add -net 127.0.0.1 192.168.255.1 255.255.255.255                                         add net 127.0.0.1: gateway 192.168.255.1 2019-05-27 14:11:00 /sbin/route add -net 0.0.0.0 10.222.29.5 128.0.0.0                                         add net 0.0.0.0: gateway 10.222.29.5 2019-05-27 14:11:00 /sbin/route add -net 128.0.0.0 10.222.29.5 128.0.0.0                                         add net 128.0.0.0: gateway 10.222.29.5 2019-05-27 14:11:00 MANAGEMENT: >STATE:1558962660,ADD_ROUTES,,,,,, 2019-05-27 14:11:00 /sbin/route add -net 10.222.29.1 10.222.29.5 255.255.255.255                                         add net 10.222.29.1: gateway 10.222.29.5 2019-05-27 14:11:00 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2019-05-27 14:11:00 Initialization Sequence Completed 2019-05-27 14:11:00 MANAGEMENT: >STATE:1558962660,CONNECTED,SUCCESS,10.222.29.6,127.0.0.1,11194,127.0.0.1,55166 2019-05-27 14:11:24 Connection reset, restarting [-1] 2019-05-27 14:11:24 /sbin/route delete -net 10.222.29.1 10.222.29.5 255.255.255.255                                         delete net 10.222.29.1: gateway 10.222.29.5 2019-05-27 14:11:24 /sbin/route delete -net 127.0.0.1 192.168.255.1 255.255.255.255                                         delete net 127.0.0.1: gateway 192.168.255.1 2019-05-27 14:11:24 /sbin/route delete -net 0.0.0.0 10.222.29.5 128.0.0.0                                         delete net 0.0.0.0: gateway 10.222.29.5 2019-05-27 14:11:24 /sbin/route delete -net 128.0.0.0 10.222.29.5 128.0.0.0                                         delete net 128.0.0.0: gateway 10.222.29.5 2019-05-27 14:11:24 Closing TUN/TAP interface 2019-05-27 14:11:24 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun2 1500 1555 10.222.29.6 10.222.29.5 init                                         **********************************************                                         Start of output from client.down.tunnelblick.sh                                         Cancelled monitoring of system configuration changes                                         Restored the DNS and SMB configurations                                         Re-enabled IPv6 (automatic) for 'iPhone USB'                                         Re-enabled IPv6 (automatic) for 'Wi-Fi'                                         Re-enabled IPv6 (automatic) for 'Bluetooth PAN'                                         Re-enabled IPv6 (automatic) for 'Thunderbolt Bridge'                                         Flushed the DNS cache via dscacheutil                                         /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil                                         Notified mDNSResponder that the DNS cache was flushed                                         End of output from client.down.tunnelblick.sh                                         ********************************************** 2019-05-27 14:11:25 SIGUSR1[soft,connection-reset] received, process restarting 2019-05-27 14:11:25 MANAGEMENT: >STATE:1558962685,RECONNECTING,connection-reset,,,,, 2019-05-27 14:11:25 *Tunnelblick: No 'reconnecting.sh' script to execute 2019-05-27 14:11:25 MANAGEMENT: CMD 'hold release' 2019-05-27 14:11:25 MANAGEMENT: CMD 'hold release' 2019-05-27 14:11:25 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2019-05-27 14:11:25 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2019-05-27 14:11:25 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2019-05-27 14:11:25 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:11194 2019-05-27 14:11:25 Socket Buffers: R=[131072->131072] S=[131072->131072] 2019-05-27 14:11:25 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11194 [nonblock] 2019-05-27 14:11:25 MANAGEMENT: >STATE:1558962685,TCP_CONNECT,,,,,, 2019-05-27 14:11:26 TCP connection established with [AF_INET]127.0.0.1:11194 2019-05-27 14:11:26 TCP_CLIENT link local: (not bound) 2019-05-27 14:11:26 TCP_CLIENT link remote: [AF_INET]127.0.0.1:11194 2019-05-27 14:11:26 MANAGEMENT: >STATE:1558962686,WAIT,,,,,, 2019-05-27 14:11:26 MANAGEMENT: >STATE:1558962686,AUTH,,,,,, 2019-05-27 14:11:26 TLS: Initial packet from [AF_INET]127.0.0.1:11194, sid=072914d3 4912c8a0 2019-05-27 14:11:26 VERIFY OK: depth=1, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=vpn@radged.com 2019-05-27 14:11:26 VERIFY KU OK 2019-05-27 14:11:26 Validating certificate extended key usage 2019-05-27 14:11:26 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2019-05-27 14:11:26 VERIFY EKU OK 2019-05-27 14:11:26 VERIFY OK: depth=0, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=vpn@radged.com 2019-05-27 14:11:26 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1552', remote='link-mtu 1544' 2019-05-27 14:11:26 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-GCM', remote='cipher BF-CBC' 2019-05-27 14:11:26 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1' 2019-05-27 14:11:26 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' 2019-05-27 14:11:26 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 2019-05-27 14:11:26 [server] Peer Connection Initiated with [AF_INET]127.0.0.1:11194 2019-05-27 14:11:26 *Tunnelblick: Disconnecting; notification window disconnect button pressed 2019-05-27 14:11:27 *Tunnelblick: No 'pre-disconnect.sh' script to execute 2019-05-27 14:11:27 *Tunnelblick: Disconnecting using 'kill' 2019-05-27 14:11:27 event_wait : Interrupted system call (code=4) 2019-05-27 14:11:27 SIGTERM[hard,] received, process exiting 2019-05-27 14:11:27 MANAGEMENT: >STATE:1558962687,EXITING,SIGTERM,,,,, 2019-05-27 14:11:27 *Tunnelblick: No 'post-disconnect.sh' script to execute 2019-05-27 14:11:27 *Tunnelblick: Expected disconnection occurred. 

VFS Global hasn’t forwarded my application to the embassy yet

I applied for a Luxembourg visa at the New Delhi VAC operated by VFS Global. It has been almost two days and as per there application tracking service, they have still not forwarded my application to the Luxembourg embassy yet. I have a trip coming in about two weeks and I am starting to get a little worried about it. How often is VFS’s tracking service not in line with the actual status of the application? It would also help if someone could tell me how long does Luxembourg take to process Schengen visas in contrast to other member states? I know for a fact that Germany, France and Switzerland are really quick.

UFW blocking SSH connection forwarded from management vlan, even when ufw is disabled

On my network, I have 2 subnets, each on their own vlan. Subnet 1’s (192.168.1.0/24) traffic is only forwarded to wan by the router. Subnet 2 (192.168.2.0/24), which I have set up as a management subnet, has its traffic forwarded to wan and subnet 1 by the router. A raspberry pi running raspbian on subnet 1 has an ssh server running. I can ssh into this pi from subnet 2 when ufw is not installed on the pi. However, when ufw is installed, I can no longer ssh into this system from subnet 2, but can from subnet 1. I have disabled ufw on the pi, but this behavior persists and can not seem to figure out what is causing this. What does ufw change in the firewall rules that could cause this behavior, even when it is not enabled?

Why are forwarded ethernet packets are being rejected at the endpoint?

I have an ESP32 wroom32 that has WiFi internally and an ethernet port. I want to be able to connect my phone to the WiFi and access a webserver running on the ethernet port. Schematically this looks like:

PC ———————– ETH (ESP32) <—-Forwarding—-> Wifi (ESP32)———— Phone

The PC has static IP: 192.168.2.150 ETH (ESP32) has static ip 192.168.2.100 Wifi (ESP) has dhcp enabled, subnet: 192.168.4.x

I am able to configure the Wifi and the ethernet part to initialize. The ETH side has a static ip and the Wifi side has DHCP to assign an IP to the phone.

I only want to access a specific webserver page running on the PC (access through 192.168.2.150:8000), this makes me think that it should be possible to have a very simple forwarding function that forwards between Wifi and ETH.

Now I have tried two things so far:

  1. Accept incoming TCP/UDP connections on the wifi interface and open an connection on the ETH interface where all the incoming wifi packets are forwarded to. This doesn’t work because the TCP connections to open to load the webpage wants to open multiple sockets. The number of sockets that can be opened are limited by the WROOM. Plus the sockets are not closed which makes me wonder how a TCP connection to load a webpage ‘knows’ that it should close. An on top op that: the webpage uses websockets to transmit data. If I understand this correctly this is another protocal than TCP which is an additional implementation.
  2. The second option is more low level. What I do is monitor the ethernet packets coming in on both interfaces. For the wifi interface: if the destination port is 8000, I change the IP addresses and HW addresses on the packet header and send it over the ETH interface. And everything coming in on the ETH interface is forwarded over the wifi interface (after changing the ip- and HW-addresses).

I think the second option is the best implementation for this problem. And I managed to get it almost working. With wireshark I can listen on both the Wifi interface and the Ethernet interface. I can see that packets are being sent and received on the other end. However when I listen with netcat the packets are not coming in.

Wireshark also gives a message that the packets are being broadcasted by an intermediate device. So my best guess is that the packets are being rejected by because of this.

To come to my question:

  • a) How is it determined that these packets are being broadcasted by an intermediate device?
  • b) Can I do something to resolve these packets being rejected?

Note: I am limited to a WROOM or some other kind of embedded device because of the characteristics that I need: It needs to be very small for an embedded application and it should have multiple interfaces for other sensors (I2C, UART, SPI)

Gmail rejects forwarded mail with DMARC but I AM using SRS

I’m forwarding mail from my domain leif@example.org to leifex@gmail.com.

I have followed this: Why is Google rejecting mails forwarded from my Postfix server?

Install pfix-srs.

Create an spf record for my mail servers domain, allowing my ip4 and ip6 to send.

(E.g. v=spf1 ip4:1.1.1.1 ip6:abcd:abc:123:4567::8 ~all)

Create an rdns entry for my mail severs domain, pointing to its IP.

My difference is I’m using postsrsd instead of pfix-srs and I’m using the domainname of my server instead of listing the ipv4 and ipv6 addresses. I have rdns to both ipv4 and ipv6.

gmail rejects the mail with 550-5.7.1 Unauthenticated email from netflix.com is not accepted due to domain's 550-5.7.1 DMARC policy.

It is as if gmail is not looking at the SRS-rewritten addresses, according to the logs the addresses DO get rewritten. What am I missing?

I am using MailScanner, so the message ids in the log gets changed in the way from received to sent.

Jan 17 22:09:10 mail postfix/smtpd[9438]: connect from a41-48.smtp-out.amazonses.com[54.240.41.48] Jan 17 22:09:11 mail postfix/smtpd[9438]: 3396B328CF: client=a41-48.smtp-out.amazonses.com[54.240.41.48] Jan 17 22:09:11 mail postsrsd[9443]: srs_forward: <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com> rewritten as                   <SRS0=YrTC=PZ=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org> Jan 17 22:09:11 mail postfix/cleanup[9442]: 3396B328CF: hold: header  Received: from a41-48.smtp-out.amazonses.com (a41-48.smtp-out.amazonses.com [54.240.41.48])??     by mail.example.org (Postfix) with ESMTPS id 3396B328CF??for <leif@example.org>; Thu, 17 Jan 2019 22:09:11 +0100     from a41-48.smtp-out.amazonses.com[54.240.41.48];     from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>     to=<leif@example.org> proto=ESMTP helo=<a41-48.smtp-out.amazonses.com> Jan 17 22:09:11 mail postfix/cleanup[9442]: 3396B328CF: message-id=<010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@email.amazonses.com> Jan 17 22:09:11 mail opendkim[812]: 3396B328CF: a41-48.smtp-out.amazonses.com [54.240.41.48] not internal Jan 17 22:09:11 mail opendkim[812]: 3396B328CF: not authenticated Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: message has signatures from netflix.com, amazonses.com Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: signature=c9tTKm4w domain=netflix.com selector=emotixlbezkp6gpvmko5lunmgwd5syff result="no signature error";     signature=VmSNlFSx domain=amazonses.com selector=ug7nbtf4gccmlpwj322ax3p6ow6yfsug result="no signature error" Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: DKIM verification successful Jan 17 22:09:12 mail opendkim[812]: 3396B328CF: s=emotixlbezkp6gpvmko5lunmgwd5syff d=netflix.com SSL Jan 17 22:09:13 mail MailScanner[31292]: Requeue: 3396B328CF.A0D92 to C662E32963 Jan 17 22:09:13 mail postfix/qmgr[9218]: C662E32963: from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,     size=89685, nrcpt=1 (queue active) Jan 17 22:09:13 mail MailScanner[31292]: Uninfected: Delivered 1 messages Jan 17 22:09:13 mail MailScanner[31292]: Deleted 1 messages from processing-database Jan 17 22:09:13 mail postfix/qmgr[9218]: 97B26328CF: from=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,     size=90760, nrcpt=1 (queue active) Jan 17 22:09:13 mail postfix/smtp[9497]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b]:25:     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) Jan 17 22:09:14 mail postfix/smtp[9497]: 97B26328CF: to=<leifex@gmail.com>, orig_to=<leif@example.org>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b]:25,     delay=0.5, delays=0.01/0/0.26/0.23, dsn=5.7.1, status=bounced     (host gmail-smtp-in.l.google.com[2a00:1450:400c:c02::1b] said:             550-5.7.1 Unauthenticated email from netflix.com is not accepted due to domain's             550-5.7.1 DMARC policy. Please contact the administrator of netflix.com domain             550-5.7.1 if this was a legitimate mail. Please visit             550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about the             550 5.7.1 DMARC initiative. j17si56462544wri.283 - gsmtp (in reply to end of DATA command)) Jan 17 22:09:14 mail postsrsd[9443]: srs_forward: <""> not rewritten: No at sign in sender address Jan 17 22:09:14 mail postsrsd[9444]:   srs_reverse: <srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>                                  rewritten as <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com> Jan 17 22:09:14 mail postsrsd[9444]: srs_reverse:   <srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>                      rewritten as <010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com> Jan 17 22:09:14 mail postfix/cleanup[9442]: 20BA932965: message-id=<20190117210914.20BA932965@mail.example.org> Jan 17 22:09:14 mail postfix/bounce[9596]: 97B26328CF: sender non-delivery notification: 20BA932965 Jan 17 22:09:14 mail postfix/qmgr[9218]: 20BA932965: from=<>, size=6444, nrcpt=1 (queue active) Jan 17 22:09:14 mail postfix/qmgr[9218]: 97B26328CF: removed Jan 17 22:09:14 mail postfix/smtp[9497]: Trusted TLS connection established to feedback-smtp.us-east-1.amazonses.com[72.21.206.91]:25:      TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jan 17 22:09:15 mail postfix/smtp[9497]: 20BA932965: to=<010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@mailer.netflix.com>,                 orig_to=<srs0=yrtc=pz=mailer.netflix.com=010001685da56f5d-8bfccbd3-896e-4700-b9a0-66e94467cab3-000000@example.org>,     relay=feedback-smtp.us-east-1.amazonses.com[72.21.206.91]:25, delay=1.4, delays=0.01/0/0.93/0.5, dsn=2.0.0, status=sent (250 Ok XCS73MIlZ28B7iH7tzWF-1) Jan 17 22:09:15 mail postfix/qmgr[9218]: 20BA932965: removed Jan 17 22:09:34 mail postfix/smtpd[9438]: disconnect from a41-48.smtp-out.amazonses.com[54.240.41.48] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7