src-nat is broken

sterhTG · Sun Jun 05, 2022 7:43 pm

Hello!
I have wired issue. I have RB3011UAS with 6.49.6 firmware running on it.
From my ISP I have network with 8IPs - XX.102.XX.24/29; Router has IP 26 on ethernet1 and it connected to ISP.
I have a server. It runs VMWare with 3 VMs. All VMs are in network 192.168.10.0/24. Server connected to Router on port 3. This is trunk port. I have a bridge with 2 VLans(data, management).
I configured dst nat for all VMs on different IPS(web, ssh etc). DST Nat rules works, But SRC-NAT does not work.
To be sure I allowed everything ad configured following rules for VM:

add action=accept chain=forward src-address=192.168.10.13
add action=dst-nat chain=dstnat dst-address=XX.218.XX.29 dst-port=80 log=yes  log-prefix=NAT_WWW protocol=tcp to-addresses=192.168.10.13
add action=dst-nat chain=dstnat dst-address=XX.218.XX.29 dst-port=443 log=yes log-prefix=NAT_HTTPS protocol=tcp to-addresses=192.168.10.13
add action=src-nat chain=srcnat out-interface=ether1-INET src-address=192.168.10.13 to-addresses=XX.218.XX.29

Does anyone able to clarify what I configured wrong?

sindy · Sun Jun 05, 2022 8:15 pm

Is that the only rule in the srcnat chain?

sterhTG · Mon Jun 06, 2022 6:47 am

No, it is not. I have 3 rules in src-nat chain. They have different source - 192.168.9.0/24, but they behave similar.
If I setup action masquerade, all rules works fine. If I setup src-nat they do not( does not depend on address, I try different - 26, 29, 27).
All Ips on router and on VMs are static.
During troubleshooting I start torch to debug. Seems src-nat is working fine. I see return packets on interface eth1(facing to ISP), on eth3(facing to VMS) I see only request packets but not responding.
I checked bridge - seems configured fine.
This souldn't be firewall Issue. To be sure I moved firewall rules to the top.

/interface bridge
add fast-forward=no name=brData protocol-mode=none pvid=1 vlan-filtering=yes
/interface vlan
add interface=brData name=vlData_VID3 vlan-id=3
add interface=brData loop-protect=on name=vlMNG_VID2 vlan-id=2
/interface bridge port
add bridge=brData comment=SRV1_vmnic2 frame-types=admit-only-vlan-tagged interface=ether3
/ip firewall filter
add action=accept chain=forward  src-address=192.168.10.13
add action=accept chain=forward dst-address=192.168.10.13

sterhTG · Mon Jun 06, 2022 6:32 pm

I added current config export. Maybe someone is able to help me.

sindy · Mon Jun 06, 2022 8:32 pm

I'd suggest to use /tool sniffer instead of /tool torch, it is much more useful for this type of debugging as it shows you individual packets with addresses and ports.

So run a ping from the VM to some address you normally don't use, make a command line window as wide as your screen allows, and run /tool sniffer quick ip-address=that.unusual.ip.address ip-protocol=icmp in that command line window. It should show you what is actually going on.

I could not spot anything wrong in your export (except that you've leaked your complete public IP, maybe you want to fix that?)

sterhTG · Tue Jun 07, 2022 4:31 am

It shows only packets from host, but do not show return packet
I added to switch rule to copy packets from port ether3, but this does not help.
At the same time torch sows return packets.

INTERFACE                              TIME    NUM DIR SRC-MAC           DST-MAC           VLAN   SRC-ADDRESS                         DST-ADDRESS                         PROTOCOL   SIZE CPU FP 
ether3                               23.306     53 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
brData                               23.306     54 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
vlData_VID3                          23.306     55 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75        192.168.10.13                       8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                          23.306     56 ->  CC:2D:E0:13:C8:74 5C:5E:AB:0A:AF:03        public.ip                       8.8.8.8                             ip:icmp      98   1 no 
ether3                                24.33     57 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
brData                                24.33     58 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
vlData_VID3                           24.33     59 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75        192.168.10.13                       8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                           24.33     60 ->  CC:2D:E0:13:C8:74 5C:5E:AB:0A:AF:03        public.ip                       8.8.8.8                             ip:icmp      98   1 no

java · Tue Jun 07, 2022 4:46 am

want lan client to access internet ip service which host on lan VM?

you should use Hairpin NAT by masquerade action to change lan to lan packets.

see https://help.mikrotik.com/docs/display/ROS/NAT, Hairpin NAT.

sterhTG · Tue Jun 07, 2022 6:11 am

want lan client to access internet ip service which host on lan VM?

you should use Hairpin NAT by masquerade action to change lan to lan packets.

see https://help.mikrotik.com/docs/display/ROS/NAT, Hairpin NAT.

No, I ping google DNS it hosted externally

sindy · Tue Jun 07, 2022 7:48 am

It shows only packets from host, but do not show return packet
...
At the same time torch sows return packets.

No idea what torch is showing you, but it's easy to get confused by torch results, especially the meaning of Rx and Tx, src and dst.

The sniffer output clearly shows that your router sends the src-nated ping responses to the gateway router (ISP's Juniper) but no responses come back to ether1-INET.

The only reasons I can imagine are the following:

there is a typo in the to-addresses, so the address is actually not from your /29, hence the response packets from 8.8.8.8 cannot come back to your router, or even the request packets don't reach their destination because the Juniper filters them out as their source address doesn't match the /29 associated with the interface to which your 3011 is connected (if rp-filter is active)
the to-addresses is correct (from the /29) but the ISP's router cannot get an ARP response from your 3011 for that address; this is less likely as you state that the dst-nat rules work properly, which means that the Juniper can deliver packets for the respective public IPs, which means it does get ARP responses for them.

The assumption of a typo is supported by the fact that in the export, there is a numeric public IP in one of the src-nat rules; if you used find&replace to substitute the actual numeric addresses by public.ip.N, a numeric address with a typo could not be substituted.

In your OP, you state the addresses are XX.102.XX.24/29, whereas this presumably incorrect address fits a XX.XX.102.24/29 pattern (102 as the third byte rather than 2nd).

sterhTG · Tue Jun 07, 2022 9:00 am

This should not be mistype. I copy and paste IP to be sure. I suppose that here in posts I make an error.
Juniper is under suspect. I played with bridge(enable RSTP, disable all ports except 1) now src-nat is working, dst does not.
I return everything back to previous state(when dst work), nothing changed.
I checked with sniffer I see outgoing packets but do not see incoming(from MTik side).

sterhTG · Tue Jun 07, 2022 11:23 am

thanks sindy !
Issue was on Juniper. ISP confirmed that minor issues was on it and now all resolved.

nichky · Wed Jun 08, 2022 5:55 am

just follow up sindy , to make it clear, how the packet sniffer should look like , in perfect scenario, if ether1 respond ?

sindy · Wed Jun 08, 2022 7:56 am

INTERFACE                              TIME    NUM DIR SRC-MAC           DST-MAC           VLAN   SRC-ADDRESS                         DST-ADDRESS                         PROTOCOL   SIZE CPU FP 
ether3                               23.306     53 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
brData                               23.306     54 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
vlData_VID3                          23.306     55 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75        192.168.10.13                       8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                          23.306     56 ->  CC:2D:E0:13:C8:74 5C:5E:AB:0A:AF:03        public.ip                           8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                          23.318     57 <-  5C:5E:AB:0A:AF:03 CC:2D:E0:13:C8:74        8.8.8.8                             public.ip                           ip:icmp      98   1 no 
vlData_VID3                          23.318     58 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95        8.8.8.8                             192.168.10.13                       ip:icmp      98   1 no 
brData                               23.318     59 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95 3      8.8.8.8                             192.168.10.13                       ip:icmp     102   1 no 
ether3                               23.318     60 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95 3      8.8.8.8                             192.168.10.13                       ip:icmp     102   1 no 
ether3                               24.306     61 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
brData                               24.306     62 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75 3      192.168.10.13                       8.8.8.8                             ip:icmp     102   1 no 
vlData_VID3                          24.306     63 <-  00:0C:29:59:6A:95 CC:2D:E0:13:C8:75        192.168.10.13                       8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                          24.306     64 ->  CC:2D:E0:13:C8:74 5C:5E:AB:0A:AF:03        public.ip                           8.8.8.8                             ip:icmp      98   1 no 
ether1-INET                          24.318     65 <-  5C:5E:AB:0A:AF:03 CC:2D:E0:13:C8:74        8.8.8.8                             public.ip                           ip:icmp      98   1 no 
vlData_VID3                          24.318     66 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95        8.8.8.8                             192.168.10.13                       ip:icmp      98   1 no 
brData                               24.318     67 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95 3      8.8.8.8                             192.168.10.13                       ip:icmp     102   1 no 
ether3                               24.318     68 ->  CC:2D:E0:13:C8:75 00:0C:29:59:6A:95 3      8.8.8.8                             192.168.10.13                       ip:icmp     102   1 no

src-nat is broken [SOLVED]

src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken [SOLVED]

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Re: src-nat is broken

Who is online