I am in the process of moving from one ISP and one wan adress to another ISP and two wan IP adresses.
the default route is 10.10.10.10, and I added two new routes to 20.20.20.20 and 30.30.30.30 ones with routing marks IP2 and IP3.
I tried out marking the packets on input coming from the new ips to the router and routing them back through the appropriate gateway, and this worked as expected.
Then I tried to make the same for dst-natting to a server on the lan, and this does not seem to work - on the original IP with default route the nat works, but on the new IP I get only tcp connection state syn sent, and not further and I cant figure out why the solutions I found on the net don´t work for me.
Could someone please tell me what is the recommended way to make the dst nat work?
It would probably be a good idea to post your config for starters.
just make one dstnat rule with the in-interface-list=wan and that way it doesnt matter if a client is coming on WAN1 or WAN2 as they get directed to the appropriate LANIP etc…
Here is the configuration I am trying now. When I try the vdsl address from outside everything works, but coming from 10.48.3.74 it does not. The mangle rules worked for getting access to the router itself from 10.48.3.74, but I can´t get it to work for the dst-nat forwarding.
On the interface vlan-airway1 I see in torch packets from IP of my pc to 10.48.3.74:3001 with only rx packets.
On the interface going to 10.0.1.3 I see packets with src 10.0.1.3 and destination IP of my pc, with packets in both directions. My suspicion is that there is something wrong with the src-nat?
Does the order of between dst-nat rule and src-nat rule matter? Is src-nat even involved in this kind of communication?
I would for troubleshooting purposes. Disable for now any mangling rules and try from a simpler setup that includes the one dstnat rule i suggested.
The router will select the same interface for return traffic from your server depending on which one it came in on with the single DSNTNAT rule.
You should have two masquerade or two srcnat rules (one for each ISP).
See if that works. If it does then its your mangle rules that need work.
When dialing in from the vlan-airway1 interface I get the first log on the nat rule, and the second one is through the vdsl.
info dst3001 dstnat: in:vlan-airway1 out:(unknown 0), src-mac cc:2d:e0:4a:55:56, proto TCP (SYN), 1.2.3.4:3182->20.20.20.20:3001, len 52
info dst3001-90 dstnat: in:vdsl out:(unknown 0), proto TCP (SYN), 1.2.3.4:3191->10.10.10.10:3001, len 52
Interesting.
Did you try and replace your vlan-airway with simply WAN (as in-interface or if you have multiple ISPs, as in-interface-list)
I will note that external users attempting to get to your servers will come in on port 3001
So either by your wanIPaddress:3001 or by dyndns type name myserver:3001
The rule you made will send those packets to internal private IP of 10.0.1.3 and translate it to port 443 at that device.
Not sure why you are using 443 because that is already a well used and designated port for HTTPS traffic.
Which is confusing without explanation. What are you trying to accomplish at this server??
Also no other funky IP firewall rules that touch upon that traffic??
Also not knowing the requirements of the server, should you have a corresponding rule for UDP traffic?
Tried replacing with interface list of the two gateways, didn´t help.
Yes, 10.0.1.3 is a server with managemnet over https interface, and I want remote access to it on a non-standard port. Before I started switching the provider I used port knocking, but now I have it disabled to debug the nat.
Firewall has only some generic accept/drop rules and nothing touches this traffic.
Well, there are other devices in the network that need similar access, and I really cannot VPN those.
Later I will try adding src nat for that specific address too, but I am not sure if it will help anythign.
Does dst-nat keep track of the whole tcp connection, so that the replies go back the same route, or how does it work?
I thought I understood how nat works, until I started playing with this…
When I add this mangle rule, nothing gets to the server, so obviously the mangle rule, along with the route rule is screwing things up. Didn´t find though where that packet leaves…
I think you are trying to do to much in one go. In fact, I think what your are attempting after re-reading is hairpin nat.
Where you can effectively use the WANIP for a server to access said server from other private IPs on the LAN.
This is a silly bugger approach that makes life far more difficult in programming and should not be used in every case.
For example, if there is no issue with accessing the server by its private LANIP from within the private LAN, this is far easier and simpler.
Even if for security purposes you dont want LAN1 users to access the server on LAN2 (closed access from LAN1 to LAN2), yes hairpin nat may solve that dilemma but why not simply create a Lan1 to LAn2 rule for that server???
I think folks seem to want this hairpin nat setup simply to test if their servers are accessible from the outside, if so just call a friend!!!
Lets get DSTNAT working first.
ONE ISP with two STATIC WANIP Addresses.
/interface list
ISP1_interface=WAN
ISP2_interface=WAN
Therefore regardless of which path a LAN requests goes out on, the request will be properly translated from private lanip to public IP.
The router will keep track of which public IP the request went out on and expect the return traffic and return it to the correct private LANIP.
However, the routing of that traffic from LAN to WAN IPs outbound still needs to be defined.
on you FIREWALL LIST you will need the following rule to allow incoming unsolicted DST NAT traffic.
/ip firewall filter
add chain=forward action=accept in-interface=wan_interface connection-nat-state=dstnat connection-state=established,related
and for multiple WANIPs.
/ip firewall filter
add chain=forward action=accept in-interface-list=wan connection-nat-state=dstnat connection-state=established,related
Ip Routes is the next step but I have run out of steam LOL.
When all is working satisfactorily then add the mangling…
I am not sure I understand what you thing I am doing in one go. I had one ISP and everything was dandy, all dst-nats worked and I need to keep it that way most of the day.
I added another ISP, and realized the dst-nats work only with the one default route where there are no route-marks (tried switching the default route without marked routes to the new isp and that routed worked, the others did not - so basically dst-nat now only works on one route, but I can choose which).
Since ideally both IPs of the new ISP will be used with marked routes to push traffic with one public IP or the other, and I would like dst-nat to work to some destinations from one IP adress, and other destinations from the other IP adress, I would like to know where the culprit is and how to configure the dst-nat properly.
Nevertheless, I will try your suggestions tomorrow and see if it I can get it to work. But please notice, that once I get rid of the old vdsl connection, I will have two local IP adresses set on one interface that leads to a single gateway at my ISP, and those are then somewhere natted to two public IPs. So the WAN list will become one interface, and I am not sure if that changes anything.