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:
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.
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?)
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
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).
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).