Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 1473 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[5.0.15] VLAN not working

techno.kid
Though I found many postings about "some" issues with VLAN and ASL I didn´t found a hint for my problem:

I´d like to use different VLANs on my Cisco switch and use ASL for routing.

What I did was extend my former configuration (no VLAN) by changing the internal interface to "VLAN ethernet interface" and add one more VLAN interface.

So far no big deal but: though I can ping my machines through the different VLANs I can NOT establish a "real" connection.

When e.g. trying to use VNC or RDP from one "real" DMZ to one of the machines in the VLAN I get a connect, can enter the password (for VNC) but than it´s hanging - same with RDP (without getting the login screen at all)!

When I change the configuration back to "Standard ethernet interface" everything is fine again.

Since the ASL interface configuration is no big deal I´d like to have you to have a look on my Cisco configuration: 
Code:
interface FastEthernet0/1
 description Firewall LAN
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1,100,101,1002-1005
 switchport mode trunk

I can see nothing false since VLAN 100 and 101 are the ones I used to play arround with.

I´d appreciate any kind of suggestion...

techno.kid


This thread was automatically locked due to age.
Parents
  • 0
    techno.kid,

    what's your address scheme for the VLANs? Do you get any suspicious entries in the packet filter log?

    read u
    o|iver
  • 0 in reply to oliver.desch
    Hi Oliver,

    my address sheme looks like this:

    Code:
    eth0:
    eth0.100:VLAN 100: 192.168.100.14/24
    eth0.101:VLAN 101: 192.168.101.14/24
    eth1: 192.168.200.14/24
    ppp0: 

    The packetfilter.log shows only ACCEPT for SYN and with tcpdump I see the whole SYN/SYN-ACK/ACK stuff including lots of PUSH packets what indicates that there is traffic ongoing between both parties.

    techno.kid
  • 0 in reply to techno.kid
    Working on this "issue" I think I tracked it down: because the targets that I can not reach have VMware on it, I beleive for some reason it´s the VMware driver that is messing up something (though I it´s deactivated).

    Additionaly I conclude that it is no good idea to define VLAN on the "Internal" interface which is created when installing ASL - this is because you can NOT delete the interface so it does not vanish in the "Network - Networks" menu - it´s still there with the status unknown.

    Maybe I can give a follow up on this VLAN issue later since I have to crosscheck with a "fresh installation" :-(

    techno.kid
  • 0 in reply to techno.kid
     [ QUOTE ]
    Additionaly I conclude that it is no good idea to define vlan on the "Internal" interface which is created when installing ASL - this is because you can NOT delete the interface so it does not vanish in the "Network - Networks" menu - it´s still there with the status unknown.

    [/ QUOTE ]
    Has this been resolved??

    I'm interested in using a cheap VIA box with only one NIC for INT,EXT,DMZ VLANs

    Thanks,
    Barry
Reply
  • 0 in reply to techno.kid
     [ QUOTE ]
    Additionaly I conclude that it is no good idea to define vlan on the "Internal" interface which is created when installing ASL - this is because you can NOT delete the interface so it does not vanish in the "Network - Networks" menu - it´s still there with the status unknown.

    [/ QUOTE ]
    Has this been resolved??

    I'm interested in using a cheap VIA box with only one NIC for INT,EXT,DMZ VLANs

    Thanks,
    Barry
Children
  • 0 in reply to BarryG
    Yes... it was my false configuration of the VMware network settings but - I maybe "discovered" another issue with the VLAN:

    I have a 3Com NIC which represents the trunk to my Cisco switch... if the MTU size of the clients is not reduced to 1492 no communication is possible. 
    Also though setting the MTU for all clients to 1492 I still have some kind of "blocking issue" (orange signal on the switch).
    Having done some research it looks like there is a "bug" in the Linux driver for the 3Com cards and I do not know if it is fixed in ASL.
    So... if i find some time for further "research" I will setup a new ASL with different NICs... until then I have to "live" with a smaller bandwith because of "bad" packets...

    techno.kid