[HELP] How to change sending interface

[octopus]

I have tried different solutions and I can't change outgoing interface when sending email.
Default interface is eth0
Does someone have any solution?

--interface tun11
-i $IFACE

sendmail -w 30 -H "exec openssl s_client -quiet -CAfile $CAFILE -connect $SMTPSERVER:$SMTPPORT -tls1_3 -starttls smtp" -f"$FROM" -au"$AUTH" -ap"$PASS" "$TO"

 

[eibgrad]

Statically bind the smtp server's IP to the VPN (tun11) in the custom config field.

route 199.199.199.199

Or else create a VPN Director rule to do the same.

 

[Ranger802004]

Statically bind the smtp server's IP to the VPN (tun11) in the custom config field.

route 199.199.199.199

Or else create a VPN Director rule to do the same.

I second this, you need to create a route for the SMTP server to use whatever interface you want whether through VPN Director or SSH.

 

[octopus]

Statically bind the smtp server's IP to the VPN (tun11) in the custom config field.

route 199.199.199.199

Or else create a VPN Director rule to do the same.

I second this, you need to create a route for the SMTP server to use whatever interface you want whether through VPN Director or SSH.

You mean this: route 173.194.221.109

Name: smtp.gmail.com
Address 1: 173.194.221.109 lm-in-f109.1e100.net

routemail 173.194.221.109 OVPN1

 

[Ranger802004]

You mean this: route 173.194.221.109


routemail 173.194.221.109 OVPN1

That and any other IPs the server resolves to, I imagine there is a list for Gmail.

 

[octopus]

That and any other IPs the server resolves to, I imagine there is a list for Gmail.

There is probably a lot of ip numbers for gmail

 

[Ranger802004]

There is probably a lot of ip numbers for gmail

I am working on a script that will do VPN routing based on domain / hostnames.

 

[octopus]

I am working on a script that will do VPN routing based on domain / hostnames.

ok, i will wait for it........

 

[eibgrad]

If you use the route directive for these purposes, it is possible to specify a domain name.

route somedomain.com 255.255.255.255 vpn_gateway

This will be resolved at the time the routes are added to the VPN's routing table, and include multiple IPs and static routes if applicable. What it won't catch is a change to the resolution should that occur sometime later. To catch any such changes, you'd have to restart the VPN. But in most cases, such changes are NOT very likely anyway.

 

[octopus]

...,

If you use the route directive for these purposes, it is possible to specify a domain name.

route somedomain.com 255.255.255.255 vpn_gateway

This will be resolved at the time the routes are added to the VPN's routing table, and include multiple IPs and static routes if applicable. What it won't catch is a change to the resolution should that occur sometime later. To catch any such changes, you'd have to restart the VPN. But in most cases, such changes are NOT very likely anyway.

I'll try it. Thanks!

 

[eibgrad]

Something else worth mentioning (as I thought more deeply about this).

Whenever you use the VPN Director (for this or other purposes), this necessarily removes the router itself from the VPN. And therefore, specifying a route directive that binds the SMTP server to the VPN is only going to affect those clients still bound to the VPN. So if the sendmail request is coming from the router itself, it will still be routed over the WAN! And since any WLAN/LAN client that's bound to the VPN is going to use the VPN by default, adding a route directive in that case is superfluous. IOW, it works, but it would have worked without the route directive anyway.

Bottomline, for all practical purposes, you have to use the VPN Director to solve this problem. That ensures the router and all other WLAN/LAN devices use the VPN for sendmail purposes. But the VPN Director doesn't support domain names. You'd have to resolve those yourself and add them as individual rules.

 

[Ranger802004]

Something else worth mentioning (as I thought more deeply about this).

Whenever you use the VPN Director (for this or other purposes), this necessarily removes the router itself from the VPN. And therefore, specifying a route directive that binds the SMTP server to the VPN is only going to affect those clients still bound to the VPN. So if the sendmail request is coming from the router itself, it will still be routed over the WAN! And since any WLAN/LAN client that's bound to the VPN is going to use the VPN by default, adding a route directive in that case is superfluous. IOW, it works, but it would have worked without the route directive anyway.

Bottomline, for all practical purposes, you have to use the VPN Director to solve this problem. That ensures the router and all other WLAN/LAN devices use the VPN for sendmail purposes. But the VPN Director doesn't support domain names. You'd have to resolve those yourself and add them as individual rules.

I have a proof of concept script already written for this, I have several domains routed over a VPN Tunnel. I am going to start working on making a public script.

 

[Martineau]

...,

I'll try it. Thanks!

FYI
ASUS Merlin: Route via VPN for specific destination hosts | Charles Wilkinson

 

[Ranger802004]

FYI
ASUS Merlin: Route via VPN for specific destination hosts | Charles Wilkinson

I had a similar setup with VPNDirector but quickly filled up max limit for it so I made my own that does the routes, iptables, and ipsets independently.

 

[Maverickcdn]

I have tried different solutions and I can't change outgoing interface when sending email.
Default interface is eth0
Does someone have any solution?

--interface tun11
-i $IFACE

Are you trying to use sendmail from the router CLI itself? ie. not a client of the router? So you want Emails sent from the router to be seen by GMail from your client VPN address?

 

[chongnt]

I had a similar setup with VPNDirector but quickly filled up max limit for it so I made my own that does the routes, iptables, and ipsets independently.

I use x3mRouting addons to manage ipsets. It can create ipsets and get the host ip from dnsmasq. It also has the capability to route the ipset to WAN or any OpenVPN client.

GitHub - Xentrk/x3mRouting: Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware

Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware - Xentrk/x3mRouting

github.com

 

[octopus]

Are you trying to use sendmail from the router CLI itself? ie. not a client of the router? So you want Emails sent from the router to be seen by GMail from your client VPN address?

Yes, from script located in /jffs/scripts/mail.sh Default it goes through eth0 want to choose between tun1-5

 

[Maverickcdn]

Yes, from script located in /jffs/scripts/mail.sh Default it goes through eth0 want to choose between tun1-5

My newb understanding is all router applets (curl, sendmail etc) are hardcoded to exit the WAN, but I could be wrong on that.

You may have to look at using IPTABLES and potentially masquerade the SMTP port to the tunnel... just spit balling

This might up @ColinTaylor alley to answer

 

[ColinTaylor]

My newb understanding is all router applets (curl, sendmail etc) are hardcoded to exit the WAN, but I could be wrong on that.

You may have to look at using IPTABLES and potentially masquerade the SMTP port to the tunnel... just spit balling

This might up @ColinTaylor alley to answer

Sorry, not really my area of expertise. This is a routing/VPN issue, not iptables.

 

[eibgrad]

My newb understanding is all router applets (curl, sendmail etc) are hardcoded to exit the WAN, but I could be wrong on that.

You may have to look at using IPTABLES and potentially masquerade the SMTP port to the tunnel... just spit balling

This might up @ColinTaylor alley to answer

They are NOT hardcoded. How a particular destination IP is routed is determined by the routing system. Specifically, the routing tables and RPDB (Routing Policy DataBase), the latter of which determines which routing tables are considered given a set of rules.

When a router is first configured, all the internet bound traffic is routed over the WAN because the rules are configured to use the default/main routing table, which has a default gateway that points to the ISP. However, something like an OpenVPN client can create additional routing tables and rules to change that default behavior. Also, static routes can be created that override the default gateway, since more specific routes are always favored over less specific routes (w/ the default gateway being the least specific route possible (0.0.0.0/0)).