InterVlan Issue - need help please

Product Discussions System
1

Hi,

Before A10 Deployment, our Core firewall was doing the InterVlan Routing.

At the moment A10 does the InterVlan Routing. While we require the Core Firewall to do that, we do have 10s of restriction policies.

I have simulated this in a testing environment and appreciate your help.

A10 InterVlan Roiuting Case
A10 InterVlan Roiuting Case515×807 64.7 KB

Here is my full configuration,

system ve-mac-scheme system-mac ! terminal idle-timeout 0 ! partition ssli_innn id 1 ! partition ssli_iouttt id 2 ! web-service axapi-timeout-policy idle 0 ! interface management ip address 192.168.1.73 255.255.255.0 enable lldp enable rx tx ! interface ethernet 1 enable ! interface ethernet 2 enable ! interface ethernet 3 ! interface ethernet 4 ! interface ethernet 5 ! interface ethernet 6 ! interface ethernet 7 ! interface ethernet 8 ! interface ethernet 9 ! interface ethernet 10 ! interface ethernet 11 ! interface ethernet 12 ! ! end ! active-partition ssli_innn ! ! access-list 190 remark ssli_innn ! access-list 190 deny ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 ! access-list 190 permit ip any any ! access-list 191 remark block_quic ! access-list 191 deny udp any any eq 80 ! access-list 191 deny udp any any eq 443 ! access-list 191 permit ip any any ! vlan 10 tagged ethernet 1 router-interface ve 10 ! vlan 20 tagged ethernet 1 router-interface ve 20 ! vlan 850 untagged ethernet 2 router-interface ve 850 ! interface ethernet 1 enable ! interface ethernet 2 enable ! interface ve 10 access-list 191 in ip address 192.168.10.1 255.255.255.0 ip allow-promiscuous-vip ! interface ve 20 access-list 191 in ip address 192.168.20.1 255.255.255.0 ip allow-promiscuous-vip ! interface ve 850 ip address 192.168.2.75 255.255.255.0 ip allow-promiscuous-vip ! ! ip route 0.0.0.0 /0 192.168.2.74 ! slb template cipher cl_cipher_template TLS1_RSA_AES_128_SHA TLS1_RSA_AES_256_SHA TLS1_RSA_AES_128_GCM_SHA256 TLS1_RSA_AES_256_GCM_SHA384 TLS1_ECDHE_RSA_AES_128_SHA TLS1_ECDHE_RSA_AES_256_SHA TLS1_ECDHE_RSA_AES_128_SHA256 TLS1_ECDHE_RSA_AES_128_GCM_SHA256 ! slb server fw1 192.168.1.76 port 0 tcp health-check-disable port 0 udp health-check-disable port 8080 tcp health-check-disable ! slb service-group SG_SSLi_TCP tcp member fw1 0 ! slb service-group SG_SSLi_UDP udp member fw1 0 ! slb service-group SG_SSLi_Xlated tcp member fw1 8080 ! slb template client-ssl cl_ssl template cipher cl_cipher_template forward-proxy-ca-cert InsightA10SSLi forward-proxy-ca-key InsightA10SSLi forward-proxy-ocsp-disable forward-proxy-crl-disable forward-proxy-cert-expiry hours 168 forward-proxy-enable forward-proxy-failsafe-disable disable-sslv3 ! slb template http insertHeaders non-http-bypass service-group SG_SSLi_Xlated ! slb virtual-server SSLi_in_ingress 0.0.0.0 acl 190 port 0 tcp service-group SG_SSLi_TCP no-dest-nat port 0 udp service-group SG_SSLi_UDP no-dest-nat port 0 others service-group SG_SSLi_UDP no-dest-nat port 443 https service-group SG_SSLi_Xlated template http insertHeaders template client-ssl cl_ssl no-dest-nat port-translation ! end !!! !!! !!! ! active-partition ssli_iouttt ! ! access-list 191 remark ssli_iouttt ! access-list 191 permit ip any any ! vlan 860 untagged ethernet 5 to 6 router-interface ve 860 ! interface ethernet 5 enable ! interface ethernet 6 enable ! interface ve 860 ip address 192.168.1.76 255.255.255.0 ip allow-promiscuous-vip ! ! ip route 0.0.0.0 /0 192.168.1.222 ! ip route 192.168.10.0 /24 192.168.1.74 ! ip route 192.168.20.0 /24 192.168.1.74 ! slb template cipher sr_cipher_template TLS1_RSA_AES_128_SHA TLS1_RSA_AES_256_SHA TLS1_RSA_AES_128_GCM_SHA256 TLS1_RSA_AES_256_GCM_SHA384 TLS1_ECDHE_RSA_AES_128_SHA TLS1_ECDHE_RSA_AES_256_SHA TLS1_ECDHE_RSA_AES_128_SHA256 TLS1_ECDHE_RSA_AES_128_GCM_SHA256 ! slb template server-ssl sr_ssl forward-proxy-enable template cipher sr_cipher_template ! slb server GW 192.168.1.222 port 0 tcp health-check-disable port 0 udp health-check-disable port 443 tcp health-check-disable ! slb service-group GW_SSL_443 tcp member GW 443 ! slb service-group GW_TCP_0 tcp member GW 0 ! slb service-group GW_UDP_0 udp member GW 0 ! slb template http removeHeaders non-http-bypass service-group GW_SSL_443 ! slb virtual-server SSLi_out_ingress 0.0.0.0 acl 191 port 0 tcp source-nat auto service-group GW_TCP_0 use-rcv-hop-for-resp no-dest-nat port 0 udp source-nat auto service-group GW_UDP_0 use-rcv-hop-for-resp no-dest-nat port 0 others source-nat auto service-group GW_UDP_0 use-rcv-hop-for-resp no-dest-nat port 443 tcp source-nat auto service-group GW_TCP_0 use-rcv-hop-for-resp no-dest-nat port 8080 http source-nat auto service-group GW_SSL_443 use-rcv-hop-for-resp template http removeHeaders template server-ssl sr_ssl no-dest-nat port-translation ! end !Current config commit point for partition 2 is 0 & config mode is classical-mode

2

If you do not want the A10 to route, do not give it interfaces in the VLAN’s. Why not create 2 partitions? and have one partition with VLAN 20 and lets say VLAN 852, and the other partition with VLAN 10 and VLAN 851? This way the traffic from VLAN 20 will stay in its own partition and thus can only reach VLAN 10 over the firewall, and the same for VLAN 10… Or have a look at: l3-vlan-fwd-disable / vlan-global l3-vlan-fwd-disable Those commands might also do what you require.

3

Actually the number of Vlans I have (+200) is more than the number of partition supports (64). l3-vlan-fwd-disable \ vlan-global l3-vlan-fwd-disable both of these commands did not have any affect. I have done 50% of my requirement, in ssli-innn partition, I have removed no access-list 190 deny ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 so all traffic now are included in the wildcard VIP. when laptop 192.168.10.100 ping 192.168.20.100, the packet goes to the firewall, and the firewall then will route it back to A10 ssli-innn partition “int ve 850”, but the issue seems int ve 850 will route it back to the firewall, I have removed “ip allow-promiscuous-vip” from ve 850, but it did no solve the issue. these are tcpdump from the firewall: 19:40:11.138585 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.138833 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.138835 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.139083 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.139085 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.139333 IP 192.168.10.100 > 192.168.20.100: ICMP echo request, id 1, seq 2999, length 40 19:40:11.139337 IP 192.168.2.74 > 192.168.10.100: ICMP time exceeded in-transit, length 36 The solution should tell ve 850 that if you receive a packet inbound (from the firewall), and destined to one of the connected Vlans, then dont use wildcard VIP, but route it normally !! I am not sure if this is possible, !!

4

Ok, it still might be possible.

You have told the A10 that it is not allowed to route between VLAN’s.
You can adjust your ACL’s so that the traffic from the firewall towards 192.168.20.100 does not hit the VIP anymore… but… then you have traffic coming from VLAN 850 that needs to be routed towards VLAN 10… with the global setting this to disable VLAN routing this will not work.

If I am correct you can also enable/disable VLAN routing on a per interface basis.
So allow VLAN routing for the VLAN 850 interface… so that traffic from the firewall gets routed normally, and disable it for all the other VLAN’s.
The routing action is decided when the traffic is inbound from an interface.

Still you now need to make sure that your SSLi VIP does not need to match on the traffic between the VLAN 10 and 20 etc… make sure you adjust the ACL’s so that the action is deny for all those IP’s.

You might actually need a second wildcard VIP with an ACL that matches you internal clients going to other internal clients and use the service group to forward the traffic to the Firewall.

And then build the ACL for the SSLi part so that only from internal sources toward external destinations are matched and processed by SSLi.

I am quite sure this is possible… I would advise getting your local A10 Representatives involved and possibly A10 Professional services if you have issues implementing the above suggestions.

5

I have played around with your setup in a lab.

And although it is possible, it’s not very straight forward. Due to the fact that you disable Inter VLAN Routing, you need to use complete VIP/ServiceGroup/Server based routing.

As far as I know you can not force traffic in the direction of a particular interface and then get the A10 to ARP for a local address, unless that address is the Server/Gateway address or you force it with aFlex.

So by disabling the “Routing” part of the A10, you now need to use Server definitions that point to Gateways for a particular destination.

Between every VLAN on the client side and the A10 you would need something that does routing, unique to that VLAN.

On thing you could possibly do to remove the need for gateways in each VLAN, it use aFlex and combine the “nexthop” command with the destination of the packet. You then force the A10 to still arp for the “nexthop” and store that MAC to forward the traffic.

So from your client side to the Firewall, you can leave the SSLi setup as is. All you need to make sure, is that the traffic that does not need SSLi, (when the source and destination are both internal) bypasses the SSLi process and get forwarded to the firewall. On the return path you can do the same. Add an ACL that matches the internal to internal traffic, this could hit a different wildcard VIP, and on that VIP use an aFlex, to force the A10 to still arp for the internal destination address and set it as next hop: nexthop [IP::addr [IP::remote_addr]]

One thing that I have not been able to test, but which might actually work. Is use the A10 in “transparent” mode.

Disable VLAN routing, have all the VLAN’s on 2 interfaces, one on the client side and one on the firewall side. When the clients ARP for their gateway, the FW will respond on the right VLAN. Now you do not need funky ACL’s or aFlex anymore.

Best would be to have A10 PS confirm this.

6

Hi diederik Thank you for your input, I have noted this and will try to lab it, However, I have re-configured my ACL and now 90% of my requirement is working fine. Here is the new ACL: access-list 190 10 deny ip any any vlan 850 access-list 190 20 permit ip any any So this tells ve 850 if you receive the packet from the firewall, dont put it in the wildcard VIP and route it normally. I can now from Vlan 10 send traffic to Vlan 20 and my firewall can see it. I have ping it as well as used RDP and both are working great. there is only one thing strange happens: in InterVlan traffic, the firewall sees duplicate packets (two packets). so if you 192.168.10.100 ping 192.168.20.100, the firewall sees two packets and not one. This only happens with InterVlan Routing, if I ping 8.8.8.8, the firewall sees only one packet. However, the computers do not see these duplicates packet, from their perspective it is fine. I have crossed check with Wireshark. Firewall tcpdump tcpdump -ni igb0 host 192.168.10.100 and icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:05:23.530228 IP 192.168.20.100 > 192.168.10.100: ICMP echo request, id 1, seq 3920, length 40 16:05:23.530239 IP 192.168.20.100 > 192.168.10.100: ICMP echo request, id 1, seq 3920, length 40 16:05:23.530978 IP 192.168.10.100 > 192.168.20.100: ICMP echo reply, id 1, seq 3920, length 40 16:05:23.530982 IP 192.168.10.100 > 192.168.20.100: ICMP echo reply, id 1, seq 3920, length 40 Firewall tcpdump tcpdump -ni igb0 host 192.168.10.100 and host 192.168.20.100 18:26:37.443725 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33049:33122, ack 331456, win 1798, length 73 18:26:37.443726 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33049:33122, ack 331456, win 1798, length 73 18:26:37.443975 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33122:33195, ack 331456, win 1798, length 73 18:26:37.443976 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33122:33195, ack 331456, win 1798, length 73 18:26:37.802975 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33195:33268, ack 331710, win 1797, length 73 18:26:37.802978 IP 192.168.10.100.55809 > 192.168.20.100.3389: Flags [P.], seq 33195:33268, ack 331710, win 1797, length 73 Here is the tracert from 192.168.20.100 to 192.168.10.100 C:\Users\hashim>tracert -d 192.168.10.100 Tracing route to 192.168.10.100 over a maximum of 30 hops 1 25 ms <1 ms <1 ms 192.168.2.74 2 <1 ms <1 ms <1 ms 192.168.2.74 3 <1 ms <1 ms <1 ms 192.168.20.1 4 1 ms 1 ms 1 ms 192.168.10.100 Trace complete. I was expecting the tracert to be something like 1 25 ms <1 ms <1 ms 192.168.20.1 2 <1 ms <1 ms <1 ms 192.168.2.74 3 <1 ms <1 ms <1 ms 192.168.2.75 4 1 ms 1 ms 1 ms 192.168.10.100 so everthing is working fine now, except this little issue, let me know if there is anything can be done on this. Thanks for your support.

7

Ok, thanks for the update.

So if I understand correctly, you now have per vlan interface on the client side used l3-vlan-fwd-disable and you have not used this on the vlan 850 interface? So that the Wildcard VIP is pushing the traffic from the VLAN’s towards the firewall, and routing from the firewall back happens normally, thanks to the ACL.

For existing SSLi sessions, the session cache should be matched first, so indeed your setup seems logical and much more easy than I cooked up :wink:

I expect the ACL + Wildcard VIP is now capturing the packets related to ping/tracrt. I don’t know why the A10 is duplicating the traffic, that should not happen.

Can you check if the A10 is also sending duplicate packets for other protocols than ICMP?

As this duplication of packets should not happen, I would definitely open a case with A10 Support so they can check it out.