InterVlan Issue - need help please

hashimhashim Member ✭
in System
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








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

Comments

  • diederikdiederik Member ✭
    edited September 2018
    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.
  • hashimhashim Member ✭
    edited September 2018
    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, !!
  • diederikdiederik Member ✭
    edited September 2018
    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.
  • diederikdiederik Member ✭
    edited September 2018
    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.
  • hashimhashim Member ✭
    edited September 2018
    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.
  • diederikdiederik Member ✭
    edited September 2018
    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 ;)

    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.
Sign In or Register to comment.

© Copyright 2024 - A10 Networks Community - All Rights Reserved. | Legal